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. 26 4月, 2018 4 次提交
  3. 25 4月, 2018 4 次提交
  4. 19 4月, 2018 1 次提交
  5. 13 4月, 2018 4 次提交
  6. 04 4月, 2018 2 次提交
  7. 30 3月, 2018 2 次提交
    • J
      nfp: flower: offload phys port MTU change · 29a5dcae
      John Hurley 提交于
      Trigger a port mod message to request an MTU change on the NIC when any
      physical port representor is assigned a new MTU value. The driver waits
      10 msec for an ack that the FW has set the MTU. If no ack is received the
      request is rejected and an appropriate warning flagged.
      
      Rather than maintain an MTU queue per repr, one is maintained per app.
      Because the MTU ndo is protected by the rtnl lock, there can never be
      contention here. Portmod messages from the NIC are also protected by
      rtnl so we first check if the portmod is an ack and, if so, handle outside
      rtnl and the cmsg work queue.
      
      Acks are detected by the marking of a bit in a portmod response. They are
      then verfied by checking the port number and MTU value expected by the
      app. If the expected MTU is 0 then no acks are currently expected.
      
      Also, ensure that the packet headroom reserved by the flower firmware is
      considered when accepting an MTU change on any repr.
      Signed-off-by: NJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      29a5dcae
    • J
      nfp: modify app MTU setting callbacks · 167cebef
      John Hurley 提交于
      Rename the 'change_mtu' app callback to 'check_mtu'. This is called
      whenever an MTU change is requested on a netdev. It can reject the
      change but is not responsible for implementing it.
      
      Introduce a new 'repr_change_mtu' app callback that is hit when the MTU
      of a repr is to be changed. This is responsible for performing the MTU
      change and verifying it.
      Signed-off-by: NJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      167cebef
  8. 29 3月, 2018 13 次提交
  9. 27 3月, 2018 3 次提交
  10. 25 3月, 2018 1 次提交
  11. 23 2月, 2018 2 次提交
  12. 17 2月, 2018 2 次提交