1. 08 Nov, 2016 2 commits
    • Jesper Dangaard Brouer's avatar
      net/qdisc: IFF_NO_QUEUE drivers should use consistent TX queue len · 11597084
      Jesper Dangaard Brouer authored
      The flag IFF_NO_QUEUE marks virtual device drivers that doesn't need a
      default qdisc attached, given they will be backed by physical device,
      that already have a qdisc attached for pushback.
      
      It is still supported to attach a qdisc to a IFF_NO_QUEUE device, as
      this can be useful for difference policy reasons (e.g. bandwidth
      limiting containers).  For this to work, the tx_queue_len need to have
      a sane value, because some qdiscs inherit/copy the tx_queue_len
      (namely, pfifo, bfifo, gred, htb, plug and sfb).
      
      Commit a813104d ("IFF_NO_QUEUE: Fix for drivers not calling
      ether_setup()") caught situations where some drivers didn't initialize
      tx_queue_len.  The problem with the commit was choosing 1 as the
      fallback value.
      
      A qdisc queue length of 1 causes more harm than good, because it
      creates hard to debug situations for userspace. It gives userspace a
      false sense of a working config after attaching a qdisc.  As low
      volume traffic (that doesn't activate the qdisc policy) works,
      like ping, while traffic that e.g. needs shaping cannot reach the
      configured policy levels, given the queue length is too small.
      
      This patch change the value to DEFAULT_TX_QUEUE_LEN, given other
      IFF_NO_QUEUE devices (that call ether_setup()) also use this value.
      
      Fixes: a813104d ("IFF_NO_QUEUE: Fix for drivers not calling ether_setup()")
      Signed-off-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      11597084
    • Jesper Dangaard Brouer's avatar
      net: make default TX queue length a defined constant · d0a81f67
      Jesper Dangaard Brouer authored
      The default TX queue length of Ethernet devices have been a magic
      constant of 1000, ever since the initial git import.
      
      Looking back in historical trees[1][2] the value used to be 100,
      with the same comment "Ethernet wants good queues". The commit[3]
      that changed this from 100 to 1000 didn't describe why, but from
      conversations with Robert Olsson it seems that it was changed
      when Ethernet devices went from 100Mbit/s to 1Gbit/s, because the
      link speed increased x10 the queue size were also adjusted.  This
      value later caused much heartache for the bufferbloat community.
      
      This patch merely moves the value into a defined constant.
      
      [1] https://git.kernel.org/cgit/linux/kernel/git/davem/netdev-vger-cvs.git/
      [2] https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/
      [3] https://git.kernel.org/tglx/history/c/98921832c232Signed-off-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0a81f67
  2. 07 Nov, 2016 21 commits
  3. 05 Nov, 2016 16 commits
  4. 04 Nov, 2016 1 commit
    • David S. Miller's avatar
      Merge branch 'nfp-ring-reconfig-and-xdp-support' · 95ae31a9
      David S. Miller authored
      Jakub Kicinski says:
      
      ====================
      ring reconfiguration and XDP support
      
      This set adds support for ethtool channel API and XDP.
      
      I kick off with ethtool get_channels() implementation.
      set_channels() needs some preparations to get right.  I follow
      the prepare/commit paradigm and allocate all resources before
      stopping the device.  It has already been done for ndo_change_mtu
      and ethtool set_ringparam(), it makes sense now to consolidate all
      the required logic in one place.
      
      XDP support requires splitting TX rings into two classes -
      for the stack and for XDP.  The ring structures are identical.
      The differences are in how they are connected to IRQ vector
      structs and how the completion/cleanup works.  When XDP is enabled
      I switch from the frag allocator to page-per-packet and map buffers
      BIDIRECTIONALly.
      
      Last but not least XDP offload is added (the patch just takes
      care of the small formal differences between cls_bpf and XDP).
      
      There is a tiny & trivial DebugFS patch in the mix, I hope it can
      be taken via net-next provided we have the right Acks.
      
      Resending with improved commit message and CCing more people on patch 10.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      95ae31a9