Eric Lee / smarc-fsl-linux-kernel

21 May, 2019

1 commit

  • 09c434b8a   treewide: Add SPDX license identifier for more missed files ... Browse Code »

    Add SPDX license identifiers to all files which:

    - Have no license information of any form

    - Have MODULE_LICENCE("GPL*") inside which was used in the initial
    scan/conversion to ignore the file

    These files fall under the project license, GPL v2 only. The resulting SPDX
    license identifier is:

    GPL-2.0-only

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

31 Jan, 2018

1 commit

  • e4823fbd2   tcp_nv: fix potential integer overflow in tcpnv_acked ... Browse Code »

    Add suffix ULL to constant 80000 in order to avoid a potential integer
    overflow and give the compiler complete information about the proper
    arithmetic to use. Notice that this constant is used in a context that
    expects an expression of type u64.

    The current cast to u64 effectively applies to the whole expression
    as an argument of type u64 to be passed to div64_u64, but it does
    not prevent it from being evaluated using 32-bit arithmetic instead
    of 64-bit arithmetic.

    Also, once the expression is properly evaluated using 64-bit arithmentic,
    there is no need for the parentheses and the external cast to u64.

    Addresses-Coverity-ID: 1357588 ("Unintentional integer overflow")
    Signed-off-by: Gustavo A. R. Silva
    Signed-off-by: David S. Miller

    Gustavo A. R. Silva
     

26 Jan, 2018

1 commit

04 Nov, 2017

2 commits

02 Nov, 2017

1 commit

22 Oct, 2017

1 commit

  • 85cce2157   bpf: Add BPF_SOCKET_OPS_BASE_RTT support to tcp_nv ... Browse Code »

    TCP_NV will try to get the base RTT from a socket_ops BPF program if one
    is loaded. NV will then use the base RTT to bound its min RTT (its
    notion of the base RTT). It uses the base RTT as an upper bound and 80%
    of the base RTT as its lower bound.

    In other words, NV will consider filtered RTTs larger than base RTT as a
    sign of congestion. As a result, there is no minRTT inflation when there
    is a lot of congestion. For example, in a DC where the RTTs are less
    than 40us when there is no congestion, a base RTT value of 80us improves
    the performance of NV. The difference between the uncongested RTT and
    the base RTT provided represents how much queueing we are willing to
    have (in practice it can be higher).

    NV has been tunned to reduce congestion when there are many flows at the
    cost of one flow not achieving full bandwith utilization. When a
    reasonable base RTT is provided, one NV flow can now fully utilize the
    full bandwidth. In addition, the performance is also improved when there
    are many flows.

    In the following examples the NV results are using a kernel with this
    patch set (i.e. both NV results are using the new nv_loss_dec_factor).

    With one host sending to another host and only one flow the
    goodputs are:
    Cubic: 9.3 Gbps, NV: 5.5 Gbps, NV (baseRTT=80us): 9.2 Gbps

    With 2 hosts sending to one host (1 flow per host, the goodput per flow
    is:
    Cubic: 4.6 Gbps, NV: 4.5 Gbps, NV (baseRTT=80us)L 4.6 Gbps

    But the RTTs seen by a ping process in the sender is:
    Cubic: 3.3ms NV: 97us, NV (baseRTT=80us): 146us

    With a lot of flows things look even better for NV with baseRTT. Here we
    have 3 hosts sending to one host. Each sending host has 6 flows: 1
    stream, 4x1MB RPC, 1x10KB RPC. Cubic, NV and NV with baseRTT all fully
    utilize the full available bandwidth. However, the distribution of
    bandwidth among the flows is very different. For the 10KB RPC flow:
    Cubic: 27Mbps, NV: 111Mbps, NV (baseRTT=80us): 222Mbps

    The 99% latencies for the 10KB flows are:
    Cubic: 26ms, NV: 1ms, NV (baseRTT=80us): 500us

    The RTT seen by a ping process at the senders:
    Cubic: 3.2ms NV: 720us, NV (baseRTT=80us): 330us

    Signed-off-by: Lawrence Brakmo
    Acked-by: Alexei Starovoitov
    Signed-off-by: David S. Miller

    Lawrence Brakmo
     

07 Aug, 2017

1 commit

  • f1722a1be   tcp: consolidate congestion control undo functions ... Browse Code »

    Most TCP congestion controls are using identical logic to undo
    cwnd except BBR. This patch consolidates these similar functions
    to the one used currently by Reno and others.

    Suggested-by: Neal Cardwell
    Signed-off-by: Yuchung Cheng
    Signed-off-by: Neal Cardwell
    Signed-off-by: David S. Miller

    Yuchung Cheng
     

22 May, 2017

1 commit

11 Jun, 2016

1 commit

  • 699fafafa   tcp: add NV congestion control ... Browse Code »

    TCP-NV (New Vegas) is a major update to TCP-Vegas.
    An earlier version of NV was presented at 2010's LPC.
    It is a delayed based congestion avoidance for the
    data center. This version has been tested within a
    10G rack where the HW RTTs are 20-50us and with
    1 to 400 flows.

    A description of TCP-NV, including implementation
    details as well as experimental results, can be found at:
    http://www.brakmo.org/networking/tcp-nv/TCPNV.html

    Signed-off-by: Lawrence Brakmo
    Signed-off-by: David S. Miller

    Lawrence Brakmo