1. 09 12月, 2016 1 次提交
  2. 03 12月, 2016 1 次提交
    • D
      bpf, xdp: drop rcu_read_lock from bpf_prog_run_xdp and move to caller · 366cbf2f
      Daniel Borkmann 提交于
      After 326fe02d ("net/mlx4_en: protect ring->xdp_prog with rcu_read_lock"),
      the rcu_read_lock() in bpf_prog_run_xdp() is superfluous, since callers
      need to hold rcu_read_lock() already to make sure BPF program doesn't
      get released in the background.
      
      Thus, drop it from bpf_prog_run_xdp(), as it can otherwise be misleading.
      Still keeping the bpf_prog_run_xdp() is useful as it allows for grepping
      in XDP supported drivers and to keep the typecheck on the context intact.
      For mlx4, this means we don't have a double rcu_read_lock() anymore. nfp can
      just make use of bpf_prog_run_xdp(), too. For qede, just move rcu_read_lock()
      out of the helper. When the driver gets atomic replace support, this will
      move to call-sites eventually.
      
      mlx5 needs actual fixing as it has the same issue as described already in
      326fe02d ("net/mlx4_en: protect ring->xdp_prog with rcu_read_lock"),
      that is, we're under RCU bh at this time, BPF programs are released via
      call_rcu(), and call_rcu() != call_rcu_bh(), so we need to properly mark
      read side as programs can get xchg()'ed in mlx5e_xdp_set() without queue
      reset.
      
      Fixes: 86994156 ("net/mlx5e: XDP fast RX drop bpf programs support")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      366cbf2f
  3. 28 11月, 2016 1 次提交
  4. 17 11月, 2016 1 次提交
    • A
      netronome: don't access real_num_rx_queues directly · 08348995
      Arnd Bergmann 提交于
      The netdev->real_num_rx_queues setting is only available if CONFIG_SYSFS
      is enabled, so we now get a build failure when that is turned off:
      
      netronome/nfp/nfp_net_common.c: In function 'nfp_net_ring_swap_enable':
      netronome/nfp/nfp_net_common.c:2489:18: error: 'struct net_device' has no member named 'real_num_rx_queues'; did you mean 'real_num_tx_queues'?
      
      As far as I can tell, the check here is only used as an optimization that
      we can skip in order to fix the compilation. If sysfs is disabled,
      the following netif_set_real_num_rx_queues() has no effect.
      
      Fixes: 164d1e9e ("nfp: add support for ethtool .set_channels")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08348995
  5. 05 11月, 2016 11 次提交
  6. 01 11月, 2016 13 次提交
  7. 18 10月, 2016 1 次提交
    • J
      ethernet: use core min/max MTU checking · 44770e11
      Jarod Wilson 提交于
      et131x: min_mtu 64, max_mtu 9216
      
      altera_tse: min_mtu 64, max_mtu 1500
      
      amd8111e: min_mtu 60, max_mtu 9000
      
      bnad: min_mtu 46, max_mtu 9000
      
      macb: min_mtu 68, max_mtu 1500 or 10240 depending on hardware capability
      
      xgmac: min_mtu 46, max_mtu 9000
      
      cxgb2: min_mtu 68, max_mtu 9582 (pm3393) or 9600 (vsc7326)
      
      enic: min_mtu 68, max_mtu 9000
      
      gianfar: min_mtu 50, max_mu 9586
      
      hns_enet: min_mtu 68, max_mtu 9578 (v1) or 9706 (v2)
      
      ksz884x: min_mtu 60, max_mtu 1894
      
      myri10ge: min_mtu 68, max_mtu 9000
      
      natsemi: min_mtu 64, max_mtu 2024
      
      nfp: min_mtu 68, max_mtu hardware-specific
      
      forcedeth: min_mtu 64, max_mtu 1500 or 9100, depending on hardware
      
      pch_gbe: min_mtu 46, max_mtu 10300
      
      pasemi_mac: min_mtu 64, max_mtu 9000
      
      qcaspi: min_mtu 46, max_mtu 1500
      - remove qcaspi_netdev_change_mtu as it is now redundant
      
      rocker: min_mtu 68, max_mtu 9000
      
      sxgbe: min_mtu 68, max_mtu 9000
      
      stmmac: min_mtu 46, max_mtu depends on hardware
      
      tehuti: min_mtu 60, max_mtu 16384
      - driver had no max mtu checking, but product docs say 16k jumbo packets
        are supported by the hardware
      
      netcp: min_mtu 68, max_mtu 9486
      - remove netcp_ndo_change_mtu as it is now redundant
      
      via-velocity: min_mtu 64, max_mtu 9000
      
      octeon: min_mtu 46, max_mtu 65370
      
      CC: netdev@vger.kernel.org
      CC: Mark Einon <mark.einon@gmail.com>
      CC: Vince Bridgers <vbridger@opensource.altera.com>
      CC: Rasesh Mody <rasesh.mody@qlogic.com>
      CC: Nicolas Ferre <nicolas.ferre@atmel.com>
      CC: Santosh Raspatur <santosh@chelsio.com>
      CC: Hariprasad S <hariprasad@chelsio.com>
      CC:  Christian Benvenuti <benve@cisco.com>
      CC: Sujith Sankar <ssujith@cisco.com>
      CC: Govindarajulu Varadarajan <_govind@gmx.com>
      CC: Neel Patel <neepatel@cisco.com>
      CC: Claudiu Manoil <claudiu.manoil@freescale.com>
      CC: Yisen Zhuang <yisen.zhuang@huawei.com>
      CC: Salil Mehta <salil.mehta@huawei.com>
      CC: Hyong-Youb Kim <hykim@myri.com>
      CC: Jakub Kicinski <jakub.kicinski@netronome.com>
      CC: Olof Johansson <olof@lixom.net>
      CC: Jiri Pirko <jiri@resnulli.us>
      CC: Byungho An <bh74.an@samsung.com>
      CC: Girish K S <ks.giri@samsung.com>
      CC: Vipul Pandya <vipul.pandya@samsung.com>
      CC: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      CC: Alexandre Torgue <alexandre.torgue@st.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Wingman Kwok <w-kwok2@ti.com>
      CC: Murali Karicheri <m-karicheri2@ti.com>
      CC: Francois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      44770e11
  8. 22 9月, 2016 3 次提交
  9. 16 9月, 2016 1 次提交
  10. 09 9月, 2016 2 次提交
  11. 12 7月, 2016 1 次提交
  12. 30 6月, 2016 1 次提交
  13. 18 6月, 2016 1 次提交
  14. 17 6月, 2016 1 次提交
  15. 17 4月, 2016 1 次提交
    • J
      nfp: add async reconfiguration mechanism · 3d780b92
      Jakub Kicinski 提交于
      Some callers of nfp_net_reconfig() are in atomic context so
      we used to busy wait for commands to complete.  In worst case
      scenario that means locking up a core for up to 5 seconds
      when a command times out.  Lets add a timer-based mechanism
      of asynchronously checking whether reconfiguration completed
      successfully for atomic callers to use.  Non-atomic callers
      can now just sleep.
      
      The approach taken is quite simple because (1) synchronous
      reconfigurations always happen under RTNL (or before device
      is registered); (2) we can coalesce pending reconfigs.
      There is no need for request queues, timer which eventually
      takes a look at reconfiguration result to report errors is
      good enough.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d780b92