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. 11 5月, 2018 1 次提交
  3. 10 5月, 2018 1 次提交
  4. 05 5月, 2018 3 次提交
    • J
      nfp: bpf: rewrite map pointers with NFP TIDs · b4264c96
      Jakub Kicinski 提交于
      Kernel will now replace map fds with actual pointer before
      calling the offload prepare.  We can identify those pointers
      and replace them with NFP table IDs instead of loading the
      table ID in code generated for CALL instruction.
      
      This allows us to support having the same CALL being used with
      different maps.
      
      Since we don't want to change the FW ABI we still need to
      move the TID from R1 to portion of R0 before the jump.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Reviewed-by: NJiong Wang <jiong.wang@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      b4264c96
    • 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
  5. 02 5月, 2018 1 次提交
  6. 27 4月, 2018 1 次提交
  7. 26 4月, 2018 4 次提交
  8. 25 4月, 2018 4 次提交
  9. 19 4月, 2018 1 次提交
  10. 13 4月, 2018 4 次提交
  11. 04 4月, 2018 2 次提交
  12. 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
  13. 29 3月, 2018 13 次提交
  14. 27 3月, 2018 2 次提交