1. 17 May, 2018 6 commits
    • Yuchung Cheng's avatar
      tcp: support DUPACK threshold in RACK · 20b654df
      Yuchung Cheng authored
      This patch adds support for the classic DUPACK threshold rule
      (#DupThresh) in RACK.
      
      When the number of packets SACKed is greater or equal to the
      threshold, RACK sets the reordering window to zero which would
      immediately mark all the unsacked packets below the highest SACKed
      sequence lost. Since this approach is known to not work well with
      reordering, RACK only uses it if no reordering has been observed.
      
      The DUPACK threshold rule is a particularly useful extension to the
      fast recoveries triggered by RACK reordering timer. For example
      data-center transfers where the RTT is much smaller than a timer
      tick, or high RTT path where the default RTT/4 may take too long.
      
      Note that this patch differs slightly from RFC6675. RFC6675
      considers a packet lost when at least #DupThresh higher-sequence
      packets are SACKed.
      
      With RACK, for connections that have seen reordering, RACK
      continues to use a dynamically-adaptive time-based reordering
      window to detect losses. But for connections on which we have not
      yet seen reordering, this patch considers a packet lost when at
      least one higher sequence packet is SACKed and the total number
      of SACKed packets is at least DupThresh. For example, suppose a
      connection has not seen reordering, and sends 10 packets, and
      packets 3, 5, 7 are SACKed. RFC6675 considers packets 1 and 2
      lost. RACK considers packets 1, 2, 4, 6 lost.
      
      There is some small risk of spurious retransmits here due to
      reordering. However, this is mostly limited to the first flight of
      a connection on which the sender receives SACKs from reordering.
      And RFC 6675 and FACK loss detection have a similar risk on the
      first flight with reordering (it's just that the risk of spurious
      retransmits from reordering was slightly narrower for those older
      algorithms due to the margin of 3*MSS).
      
      Also the minimum reordering window is reduced from 1 msec to 0
      to recover quicker on short RTT transfers. Therefore RACK is more
      aggressive in marking packets lost during recovery to reduce the
      reordering window timeouts.
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Reviewed-by: default avatarPriyaranjan Jha <priyarjha@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20b654df
    • Ivan Khoronzhuk's avatar
      net: ethernet: ti: cpsw: disable mq feature for "AM33xx ES1.0" devices · 9611d6d6
      Ivan Khoronzhuk authored
      The early versions of am33xx devices, related to ES1.0 SoC revision
      have errata limiting mq support. That's the same errata as
      commit 7da11600 ("drivers: net: cpsw: add am335x errata workarround for
      interrutps")
      
      AM33xx Errata [1] Advisory 1.0.9
      http://www.ti.com/lit/er/sprz360f/sprz360f.pdf
      
      After additional investigation were found that drivers w/a is
      propagated on all AM33xx SoCs and on DM814x. But the errata exists
      only for ES1.0 of AM33xx family, limiting mq support for revisions
      after ES1.0. So, disable mq support only for related SoCs and use
      separate polls for revisions allowing mq.
      Signed-off-by: default avatarIvan Khoronzhuk <ivan.khoronzhuk@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9611d6d6
    • David S. Miller's avatar
      Merge branch 'sched-refactor-NOLOCK-qdiscs' · 4b9c7768
      David S. Miller authored
      Paolo Abeni says:
      
      ====================
      sched: refactor NOLOCK qdiscs
      
      With the introduction of NOLOCK qdiscs, pfifo_fast performances in the
      uncontended scenario degraded measurably, especially after the commit
      eb82a994 ("net: sched, fix OOO packets with pfifo_fast").
      
      This series restore the pfifo_fast performances in such scenario back the
      previous level, mainly reducing the number of atomic operations required to
      perform the qdisc_run() call. Even performances in the contended scenario
      increase measurably.
      
      Note: This series is on top of:
      
      sched: manipulate __QDISC_STATE_RUNNING in qdisc_run_* helpers
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b9c7768
    • Paolo Abeni's avatar
      pfifo_fast: drop unneeded additional lock on dequeue · 021a17ed
      Paolo Abeni authored
      After the previous patch, for NOLOCK qdiscs, q->seqlock is
      always held when the dequeue() is invoked, we can drop
      any additional locking to protect such operation.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      021a17ed
    • Paolo Abeni's avatar
      sched: replace __QDISC_STATE_RUNNING bit with a spin lock · 96009c7d
      Paolo Abeni authored
      So that we can use lockdep on it.
      The newly introduced sequence lock has the same scope of busylock,
      so it shares the same lockdep annotation, but it's only used for
      NOLOCK qdiscs.
      
      With this changeset we acquire such lock in the control path around
      flushing operation (qdisc reset), to allow more NOLOCK qdisc perf
      improvement in the next patch.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      96009c7d
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next · b9f672af
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf-next 2018-05-17
      
      The following pull-request contains BPF updates for your *net-next* tree.
      
      The main changes are:
      
      1) Provide a new BPF helper for doing a FIB and neighbor lookup
         in the kernel tables from an XDP or tc BPF program. The helper
         provides a fast-path for forwarding packets. The API supports
         IPv4, IPv6 and MPLS protocols, but currently IPv4 and IPv6 are
         implemented in this initial work, from David (Ahern).
      
      2) Just a tiny diff but huge feature enabled for nfp driver by
         extending the BPF offload beyond a pure host processing offload.
         Offloaded XDP programs are allowed to set the RX queue index and
         thus opening the door for defining a fully programmable RSS/n-tuple
         filter replacement. Once BPF decided on a queue already, the device
         data-path will skip the conventional RSS processing completely,
         from Jakub.
      
      3) The original sockmap implementation was array based similar to
         devmap. However unlike devmap where an ifindex has a 1:1 mapping
         into the map there are use cases with sockets that need to be
         referenced using longer keys. Hence, sockhash map is added reusing
         as much of the sockmap code as possible, from John.
      
      4) Introduce BTF ID. The ID is allocatd through an IDR similar as
         with BPF maps and progs. It also makes BTF accessible to user
         space via BPF_BTF_GET_FD_BY_ID and adds exposure of the BTF data
         through BPF_OBJ_GET_INFO_BY_FD, from Martin.
      
      5) Enable BPF stackmap with build_id also in NMI context. Due to the
         up_read() of current->mm->mmap_sem build_id cannot be parsed.
         This work defers the up_read() via a per-cpu irq_work so that
         at least limited support can be enabled, from Song.
      
      6) Various BPF JIT follow-up cleanups and fixups after the LD_ABS/LD_IND
         JIT conversion as well as implementation of an optimized 32/64 bit
         immediate load in the arm64 JIT that allows to reduce the number of
         emitted instructions; in case of tested real-world programs they
         were shrinking by three percent, from Daniel.
      
      7) Add ifindex parameter to the libbpf loader in order to enable
         BPF offload support. Right now only iproute2 can load offloaded
         BPF and this will also enable libbpf for direct integration into
         other applications, from David (Beckett).
      
      8) Convert the plain text documentation under Documentation/bpf/ into
         RST format since this is the appropriate standard the kernel is
         moving to for all documentation. Also add an overview README.rst,
         from Jesper.
      
      9) Add __printf verification attribute to the bpf_verifier_vlog()
         helper. Though it uses va_list we can still allow gcc to check
         the format string, from Mathieu.
      
      10) Fix a bash reference in the BPF selftest's Makefile. The '|& ...'
          is a bash 4.0+ feature which is not guaranteed to be available
          when calling out to shell, therefore use a more portable variant,
          from Joe.
      
      11) Fix a 64 bit division in xdp_umem_reg() by using div_u64()
          instead of relying on the gcc built-in, from Björn.
      
      12) Fix a sock hashmap kmalloc warning reported by syzbot when an
          overly large key size is used in hashmap then causing overflows
          in htab->elem_size. Reject bogus attr->key_size early in the
          sock_hash_alloc(), from Yonghong.
      
      13) Ensure in BPF selftests when urandom_read is being linked that
          --build-id is always enabled so that test_stacktrace_build_id[_nmi]
          won't be failing, from Alexei.
      
      14) Add bitsperlong.h as well as errno.h uapi headers into the tools
          header infrastructure which point to one of the arch specific
          uapi headers. This was needed in order to fix a build error on
          some systems for the BPF selftests, from Sirio.
      
      15) Allow for short options to be used in the xdp_monitor BPF sample
          code. And also a bpf.h tools uapi header sync in order to fix a
          selftest build failure. Both from Prashant.
      
      16) More formally clarify the meaning of ID in the direct packet access
          section of the BPF documentation, from Wang.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b9f672af
  2. 16 May, 2018 34 commits