1. 10 Dec, 2016 8 commits
    • David S. Miller's avatar
      Merge branch 'udp-receive-path-optimizations' · 524a64c7
      David S. Miller authored
      Eric Dumazet says:
      
      ====================
      udp: receive path optimizations
      
      This patch series provides about 100 % performance increase under flood.
      
      v2: added Paolo feedback on udp_rmem_release() for tiny sk_rcvbuf
          added the last patch touching sk_rmem_alloc later
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      524a64c7
    • Eric Dumazet's avatar
      udp: udp_rmem_release() should touch sk_rmem_alloc later · 02ab0d13
      Eric Dumazet authored
      In flood situations, keeping sk_rmem_alloc at a high value
      prevents producers from touching the socket.
      
      It makes sense to lower sk_rmem_alloc only at the end
      of udp_rmem_release() after the thread draining receive
      queue in udp_recvmsg() finished the writes to sk_forward_alloc.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      02ab0d13
    • Eric Dumazet's avatar
      udp: add batching to udp_rmem_release() · 6b229cf7
      Eric Dumazet authored
      If udp_recvmsg() constantly releases sk_rmem_alloc
      for every read packet, it gives opportunity for
      producers to immediately grab spinlocks and desperatly
      try adding another packet, causing false sharing.
      
      We can add a simple heuristic to give the signal
      by batches of ~25 % of the queue capacity.
      
      This patch considerably increases performance under
      flood by about 50 %, since the thread draining the queue
      is no longer slowed by false sharing.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b229cf7
    • Eric Dumazet's avatar
      udp: copy skb->truesize in the first cache line · c84d9490
      Eric Dumazet authored
      In UDP RX handler, we currently clear skb->dev before skb
      is added to receive queue, because device pointer is no longer
      available once we exit from RCU section.
      
      Since this first cache line is always hot, lets reuse this space
      to store skb->truesize and thus avoid a cache line miss at
      udp_recvmsg()/udp_skb_destructor time while receive queue
      spinlock is held.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c84d9490
    • Eric Dumazet's avatar
      udp: add busylocks in RX path · 4b272750
      Eric Dumazet authored
      Idea of busylocks is to let producers grab an extra spinlock
      to relieve pressure on the receive_queue spinlock shared by consumer.
      
      This behavior is requested only once socket receive queue is above
      half occupancy.
      
      Under flood, this means that only one producer can be in line
      trying to acquire the receive_queue spinlock.
      
      These busylock can be allocated on a per cpu manner, instead of a
      per socket one (that would consume a cache line per socket)
      
      This patch considerably improves UDP behavior under stress,
      depending on number of NIC RX queues and/or RPS spread.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b272750
    • David S. Miller's avatar
      Merge branch 'qcom-emac' · d96dac14
      David S. Miller authored
      Timur Tabi says:
      
      ====================
      net: qcom/emac: simplify support for different SOCs
      
      On SOCs that have the Qualcomm EMAC network controller, the internal
      PHY block is always different.  Sometimes the differences are small,
      sometimes it might be a completely different IP.  Either way, using version
      numbers to differentiate them and putting all of the init code in one
      file does not scale.
      
      This patchset does two things:  The first breaks up the current code into
      different files, and the second patch adds support for a third SOC, the
      Qualcomm Technologies QDF2400 ARM Server SOC.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d96dac14
    • Timur Tabi's avatar
      net: qcom/emac: add support for the Qualcomm Technologies QDF2400 · a51f4047
      Timur Tabi authored
      The QDF2432 and the QDF2400 have slightly different internal PHYs,
      so there are some programming differences.  Some of the registers in
      the QDF2400 have moved, and some registers require different values
      during initialization.
      
      Because of the differences, and because HIDs are a scare resource,
      the ACPI tables specify the hardware version in an _HRV property.
      Version 1 is the QDF2432, and version 2 is the QDF2400.  Any future
      SOC that has the same internal PHY but different programming
      requirements will be assigned the next available version number.
      Signed-off-by: default avatarTimur Tabi <timur@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a51f4047
    • Timur Tabi's avatar
      net: qcom/emac: move phy init code to separate files · 1e88ab6f
      Timur Tabi authored
      The internal PHY of the EMAC differs on each SOC, and the list will
      only continue to grow.  By separating the code into individual files,
      we can add support for more SOCs more cleanly.
      
      Note: The internal PHY is also sometimes called the SGMII device.
      
      We also stop referring to the various PHY variations by version number,
      so no more "v2", "v3", etc.  Instead, the devices are named after the
      SOC they are, which is in sync with the device tree property names.
      
      Future patches will probably rearrange more code among the files.
      Signed-off-by: default avatarTimur Tabi <timur@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e88ab6f
  2. 09 Dec, 2016 3 commits
    • Arnd Bergmann's avatar
      net: xgene: avoid bogus maybe-uninitialized warning · f006b2c5
      Arnd Bergmann authored
      In some configurations, gcc cannot trace the state of variables
      across a spin_unlock() barrier, leading to a warning about
      correct code:
      
      xgene_enet_main.c: In function 'xgene_enet_start_xmit':
      ../../../phy/mdio-xgene.h:112:14: error: 'mss_index' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      Here we can trivially move the assignment before that spin_unlock,
      which reliably avoids the warning.
      
      Fixes: e3978673 ("drivers: net: xgene: Fix MSS programming")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f006b2c5
    • Arnd Bergmann's avatar
      net: xgene: move xgene_cle_ptree_ewdn data off stack · dece303f
      Arnd Bergmann authored
      The array for initializing the cle is set up on the stack with
      almost entirely constant data and then passed to a function that
      converts it into HW specific bit patterns. With the latest
      addition, the size of this array has grown to the point that
      we get a warning about potential stack overflow in allmodconfig
      builds:
      
      xgene_enet_cle.c: In function ‘xgene_enet_cle_init’:
      xgene_enet_cle.c:836:1: error: the frame size of 1032 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      
      Looking a bit deeper at the usage, I noticed that the only modification
      of the data is in dead code, as we don't even use the cle module
      for phy_mode other than PHY_INTERFACE_MODE_XGMII. This means we
      can simply mark the structure constant and access it directly rather
      than passing the pointer down through another structure, making
      the code more efficient at the same time as avoiding the
      warning.
      
      Fixes: a809701f ("drivers: net: xgene: fix: RSS for non-TCP/UDP")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dece303f
    • Arnd Bergmann's avatar
      net/mlx5e: use %pad format string for dma_addr_t · 9afd8952
      Arnd Bergmann authored
      On 32-bit ARM with 64-bit dma_addr_t I get this warning about an
      incorrect format string:
      
      In file included from /git/arm-soc/drivers/net/ethernet/mellanox/mlx5/core/alloc.c:42:0:
      drivers/net/ethernet/mellanox/mlx5/core/alloc.c: In function ‘mlx5_frag_buf_alloc_node’:
      drivers/net/ethernet/mellanox/mlx5/core/alloc.c:134:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
      
      We have the special %pad format for printing dma_addr_t, so use that
      to print the correct address and avoid the warning.
      
      Fixes: 1c1b5228 ("net/mlx5e: Implement Fragmented Work Queue (WQ)")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9afd8952
  3. 08 Dec, 2016 29 commits