1. 19 5月, 2018 1 次提交
    • J
      nfp: bpf: support logic indirect shifts (BPF_[L|R]SH | BPF_X) · 991f5b36
      Jiong Wang 提交于
      For indirect shifts, shift amount is not specified as constant, NFP needs
      to get the shift amount through the low 5 bits of source A operand in
      PREV_ALU, therefore extra instructions are needed compared with shifts by
      constants.
      
      Because NFP is 32-bit, so we are using register pair for 64-bit shifts and
      therefore would need different instruction sequences depending on whether
      shift amount is less than 32 or not.
      
      NFP branch-on-bit-test instruction emitter is added by this patch and is
      used for efficient runtime check on shift amount. We'd think the shift
      amount is less than 32 if bit 5 is clear and greater or equal than 32
      otherwise. Shift amount is greater than or equal to 64 will result in
      undefined behavior.
      
      This patch also use range info to avoid generating unnecessary runtime code
      if we are certain shift amount is less than 32 or not.
      Signed-off-by: NJiong Wang <jiong.wang@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      991f5b36
  2. 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
  3. 29 3月, 2018 1 次提交
  4. 23 1月, 2018 1 次提交
  5. 19 1月, 2018 1 次提交
  6. 18 1月, 2018 1 次提交
  7. 15 1月, 2018 2 次提交
  8. 10 1月, 2018 5 次提交
  9. 15 12月, 2017 1 次提交
  10. 02 12月, 2017 2 次提交
  11. 21 11月, 2017 1 次提交
  12. 05 11月, 2017 7 次提交
  13. 02 11月, 2017 1 次提交
  14. 27 10月, 2017 1 次提交
  15. 24 10月, 2017 2 次提交
  16. 05 8月, 2017 1 次提交
  17. 01 6月, 2017 3 次提交
  18. 01 5月, 2017 1 次提交
  19. 13 3月, 2017 1 次提交
  20. 10 3月, 2017 1 次提交
  21. 05 11月, 2016 2 次提交
  22. 14 10月, 2016 1 次提交
  23. 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