1. 05 5月, 2018 2 次提交
    • J
      nfp: bpf: perf event output helpers support · 9816dd35
      Jakub Kicinski 提交于
      Add support for the perf_event_output family of helpers.
      
      The implementation on the NFP will not match the host code exactly.
      The state of the host map and rings is unknown to the device, hence
      device can't return errors when rings are not installed.  The device
      simply packs the data into a firmware notification message and sends
      it over to the host, returning success to the program.
      
      There is no notion of a host CPU on the device when packets are being
      processed.  Device will only offload programs which set BPF_F_CURRENT_CPU.
      Still, if map index doesn't match CPU no error will be returned (see
      above).
      
      Dropped/lost firmware notification messages will not cause "lost
      events" event on the perf ring, they are only visible via device
      error counters.
      
      Firmware notification messages may also get reordered in respect
      to the packets which caused their generation.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      9816dd35
    • J
      nfp: bpf: record offload neutral maps in the driver · 630a4d38
      Jakub Kicinski 提交于
      For asynchronous events originating from the device, like perf event
      output, we need to be able to make sure that objects being referred
      to by the FW message are valid on the host.  FW events can get queued
      and reordered.  Even if we had a FW message "barrier" we should still
      protect ourselves from bogus FW output.
      
      Add a reverse-mapping hash table and record in it all raw map pointers
      FW may refer to.  Only record neutral maps, i.e. perf event arrays.
      These are currently the only objects FW can refer to.  Use RCU protection
      on the read side, update side is under RTNL.
      
      Since program vs map destruction order is slightly painful for offload
      simply take an extra reference on all the recorded maps to make sure
      they don't disappear.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      630a4d38
  2. 29 3月, 2018 1 次提交
  3. 23 1月, 2018 1 次提交
  4. 19 1月, 2018 1 次提交
  5. 18 1月, 2018 1 次提交
  6. 15 1月, 2018 2 次提交
  7. 10 1月, 2018 5 次提交
  8. 15 12月, 2017 1 次提交
  9. 02 12月, 2017 2 次提交
  10. 21 11月, 2017 1 次提交
  11. 05 11月, 2017 7 次提交
  12. 02 11月, 2017 1 次提交
  13. 27 10月, 2017 1 次提交
  14. 24 10月, 2017 2 次提交
  15. 05 8月, 2017 1 次提交
  16. 01 6月, 2017 3 次提交
  17. 01 5月, 2017 1 次提交
  18. 13 3月, 2017 1 次提交
  19. 10 3月, 2017 1 次提交
  20. 05 11月, 2016 2 次提交
  21. 14 10月, 2016 1 次提交
  22. 26 9月, 2016 1 次提交
    • A
      nfp: bpf: improve handling for disabled BPF syscall · b47c62c5
      Arnd Bergmann 提交于
      I stumbled over a new warning during randconfig testing,
      with CONFIG_BPF_SYSCALL disabled:
      
      drivers/net/ethernet/netronome/nfp/nfp_net_offload.c: In function 'nfp_net_bpf_offload':
      drivers/net/ethernet/netronome/nfp/nfp_net_offload.c:263:3: error: '*((void *)&res+4)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      drivers/net/ethernet/netronome/nfp/nfp_net_offload.c:263:3: error: 'res.n_instr' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      As far as I can tell, this is a false positive caused by the compiler
      getting confused about a function that is partially inlined, but it's
      easy to avoid while improving the code:
      
      The nfp_bpf_jit() stub helper for that configuration is unusual as it
      is defined in a header file but not marked 'static inline'. By moving
      the compile-time check into the caller using the IS_ENABLED() macro,
      we can remove that stub and simplify the nfp_net_bpf_offload_prepare()
      function enough to unconfuse the compiler.
      
      Fixes: 7533fdc0 ("nfp: bpf: add hardware bpf offload")
      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>
      b47c62c5
  23. 22 9月, 2016 1 次提交