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. 25 4月, 2018 4 次提交
  3. 30 3月, 2018 1 次提交
  4. 29 3月, 2018 13 次提交
  5. 25 3月, 2018 1 次提交
  6. 23 2月, 2018 1 次提交
  7. 08 2月, 2018 2 次提交
  8. 07 2月, 2018 1 次提交
  9. 26 1月, 2018 1 次提交
  10. 23 1月, 2018 2 次提交
  11. 20 1月, 2018 2 次提交
  12. 19 1月, 2018 2 次提交
  13. 18 1月, 2018 1 次提交
  14. 17 1月, 2018 2 次提交
  15. 15 1月, 2018 5 次提交