1. 10 3月, 2017 2 次提交
  2. 04 3月, 2017 2 次提交
  3. 11 2月, 2017 1 次提交
  4. 26 1月, 2017 1 次提交
    • D
      bpf: add initial bpf tracepoints · a67edbf4
      Daniel Borkmann 提交于
      This work adds a number of tracepoints to paths that are either
      considered slow-path or exception-like states, where monitoring or
      inspecting them would be desirable.
      
      For bpf(2) syscall, tracepoints have been placed for main commands
      when they succeed. In XDP case, tracepoint is for exceptions, that
      is, f.e. on abnormal BPF program exit such as unknown or XDP_ABORTED
      return code, or when error occurs during XDP_TX action and the packet
      could not be forwarded.
      
      Both have been split into separate event headers, and can be further
      extended. Worst case, if they unexpectedly should get into our way in
      future, they can also removed [1]. Of course, these tracepoints (like
      any other) can be analyzed by eBPF itself, etc. Example output:
      
        # ./perf record -a -e bpf:* sleep 10
        # ./perf script
        sock_example  6197 [005]   283.980322:      bpf:bpf_map_create: map type=ARRAY ufd=4 key=4 val=8 max=256 flags=0
        sock_example  6197 [005]   283.980721:       bpf:bpf_prog_load: prog=a5ea8fa30ea6849c type=SOCKET_FILTER ufd=5
        sock_example  6197 [005]   283.988423:   bpf:bpf_prog_get_type: prog=a5ea8fa30ea6849c type=SOCKET_FILTER
        sock_example  6197 [005]   283.988443: bpf:bpf_map_lookup_elem: map type=ARRAY ufd=4 key=[06 00 00 00] val=[00 00 00 00 00 00 00 00]
        [...]
        sock_example  6197 [005]   288.990868: bpf:bpf_map_lookup_elem: map type=ARRAY ufd=4 key=[01 00 00 00] val=[14 00 00 00 00 00 00 00]
             swapper     0 [005]   289.338243:    bpf:bpf_prog_put_rcu: prog=a5ea8fa30ea6849c type=SOCKET_FILTER
      
        [1] https://lwn.net/Articles/705270/Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a67edbf4
  5. 09 1月, 2017 1 次提交
  6. 09 12月, 2016 1 次提交
  7. 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
  8. 28 11月, 2016 1 次提交
  9. 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
  10. 05 11月, 2016 11 次提交
  11. 01 11月, 2016 13 次提交
  12. 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
  13. 22 9月, 2016 3 次提交
  14. 16 9月, 2016 1 次提交