1. 23 Nov, 2015 7 commits
  2. 22 Nov, 2015 2 commits
  3. 20 Nov, 2015 26 commits
  4. 18 Nov, 2015 5 commits
    • David S. Miller's avatar
      Merge branch 'net-generic-busy-polling' · 85c72ba1
      David S. Miller authored
      Eric Dumazet says:
      
      ====================
      net: extend busy polling support
      
      This patch series extends busy polling range to tunnels devices,
      and adds busy polling generic support to all NAPI drivers.
      
      No need to provide ndo_busy_poll() method and extra synchronization
      between ndo_busy_poll() and normal napi->poll() method.
      This was proven very difficult and bug prone.
      
      mlx5 driver is changed to support busy polling using this new method,
      and a second mlx5 patch adds napi_complete_done() support and proper
      SNMP accounting.
      
      bnx2x and mlx4 drivers are converted to new infrastructure,
      reducing kernel bloat and improving performance.
      
      Latest patch, adding generic support, adds a new requirement :
      
       -free_netdev() and netif_napi_del() must be called from process context.
      
      Since this might not be the case in some drivers, we might have to
      either : fix the non conformant drivers (by disabling busy polling on them)
      or revert this last patch.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      85c72ba1
    • Eric Dumazet's avatar
      net: provide generic busy polling to all NAPI drivers · 93d05d4a
      Eric Dumazet authored
      NAPI drivers no longer need to observe a particular protocol
      to benefit from busy polling (CONFIG_NET_RX_BUSY_POLL=y)
      
      napi_hash_add() and napi_hash_del() are automatically called
      from core networking stack, respectively from
      netif_napi_add() and netif_napi_del()
      
      This patch depends on free_netdev() and netif_napi_del() being
      called from process context, which seems to be the norm.
      
      Drivers might still prefer to call napi_hash_del() on their
      own, since they might combine all the rcu grace periods into
      a single one, knowing their NAPI structures lifetime, while
      core networking stack has no idea of a possible combining.
      
      Once this patch proves to not bring serious regressions,
      we will cleanup drivers to either remove napi_hash_del()
      or provide appropriate rcu grace periods combining.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93d05d4a
    • Eric Dumazet's avatar
      net: napi_hash_del() returns a boolean status · 34cbe27e
      Eric Dumazet authored
      napi_hash_del() will soon be used from both drivers (if they want)
      or core networking stack.
      
      Callers are responsibles to ensure an RCU grace period is respected
      before freeing napi structure : napi_hash_del() can signal if
      this RCU grace period is needed or not.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      34cbe27e
    • Eric Dumazet's avatar
      net: move napi_hash[] into read mostly section · 6180d9de
      Eric Dumazet authored
      We do not often add/delete a napi context.
      Moving napi_hash[] into read mostly section avoids potential false sharing.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6180d9de
    • Eric Dumazet's avatar
      net: add netif_tx_napi_add() · d64b5e85
      Eric Dumazet authored
      netif_tx_napi_add() is a variant of netif_napi_add()
      
      It should be used by drivers that use a napi structure
      to exclusively poll TX.
      
      We do not want to add this kind of napi in napi_hash[] in following
      patches, adding generic busy polling to all NAPI drivers.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d64b5e85