1. 02 6月, 2020 1 次提交
  2. 30 5月, 2020 1 次提交
  3. 20 5月, 2020 2 次提交
  4. 28 9月, 2019 2 次提交
  5. 07 8月, 2019 1 次提交
    • J
      nfp: flower: offload pre-tunnel rules · f12725d9
      John Hurley 提交于
      Pre-tunnel rules are TC flower and OvS rules that forward a packet to the
      tunnel end point where it can then pass through the network stack and be
      decapsulated. These are required if the tunnel end point is, say, an OvS
      internal port.
      
      Currently, firmware determines that a packet is in a tunnel and decaps it
      if it has a known destination IP and MAC address. However, this bypasses
      the flower pre-tunnel rule and so does not update the stats. Further to
      this it ignores VLANs that may exist outside of the tunnel header.
      
      Offload pre-tunnel rules to the NFP. This embeds the pre-tunnel rule into
      the tunnel decap process based on (firmware) mac index and VLAN. This
      means that decap can be carried out correctly with VLANs and that stats
      can be updated for all kernel rules correctly.
      Signed-off-by: NJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: NSimon Horman <simon.horman@netronome.com>
      Acked-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f12725d9
  6. 06 5月, 2019 1 次提交
  7. 16 4月, 2019 4 次提交
  8. 17 1月, 2019 4 次提交
    • J
      nfp: flower: enable MAC address sharing for offloadable devs · 20cce886
      John Hurley 提交于
      A MAC address is not necessarily a unique identifier for a netdev. Drivers
      such as Linux bonds, for example, can apply the same MAC address to the
      upper layer device and all lower layer devices.
      
      NFP MAC offload for tunnel decap includes port verification for reprs but
      also supports the offload of non-repr MAC addresses by assigning 'global'
      indexes to these. This means that the FW will not verify the incoming port
      of a packet matching this destination MAC.
      
      Modify the MAC offload logic to assign global indexes based on MAC address
      instead of net device (as it currently does). Use this to allow multiple
      devices to share the same MAC. In other words, if a repr shares its MAC
      address with another device then give the offloaded MAC a global index
      rather than associate it with an ingress port. Track this so that changes
      can be reverted as MACs stop being shared.
      
      Implement this by removing the current list based assignment of global
      indexes and replacing it with an rhashtable that maps an offloaded MAC
      address to the number of devices sharing it, distributing global indexes
      based on this.
      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>
      20cce886
    • J
      nfp: flower: add infastructure for non-repr priv data · 05d2bee6
      John Hurley 提交于
      NFP repr netdevs contain private data that can store per port information.
      In certain cases, the NFP driver offloads information from non-repr ports
      (e.g. tunnel ports). As the driver does not have control over non-repr
      netdevs, it cannot add/track private data directly to the netdev struct.
      
      Add infastructure to store private information on any non-repr netdev that
      is offloaded at a given time. This is used in a following patch to track
      offloaded MAC addresses for non-reprs and enable correct house keeping on
      address changes.
      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>
      05d2bee6
    • P
      nfp: flower: support multiple memory units for filter offloads · 467322e2
      Pieter Jansen van Vuuren 提交于
      Adds support for multiple memory units which are used for filter
      offloads. Each filter is assigned a stats id, the MSBs of the id are
      used to determine which memory unit the filter should be offloaded
      to. The number of available memory units that could be used for filter
      offload is obtained from HW. A simple round robin technique is used to
      allocate and distribute the ids across memory units.
      Signed-off-by: NPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      467322e2
    • F
      nfp: flower: increase cmesg reply timeout · 96439889
      Fred Lotter 提交于
      QA tests report occasional timeouts on REIFY message replies. Profiling
      of the two cmesg reply types under burst conditions, with a 12-core host
      under heavy cpu and io load (stress --cpu 12 --io 12), show both PHY MTU
      change and REIFY replies can exceed the 10ms timeout. The maximum MTU
      reply wait under burst is 16ms, while the maximum REIFY wait under 40 VF
      burst is 12ms. Using a 4 VF REIFY burst results in an 8ms maximum wait.
      A larger VF burst does increase the delay, but not in a linear enough
      way to justify a scaled REIFY delay. The worse case values between
      MTU and REIFY appears close enough to justify a common timeout. Pick a
      conservative 40ms to make a safer future proof common reply timeout. The
      delay only effects the failure case.
      
      Change the REIFY timeout mechanism to use wait_event_timeout() instead
      of wait_event_interruptible_timeout(), to match the MTU code. In the
      current implementation, theoretically, a signal could interrupt the
      REIFY waiting period, with a return code of ERESTARTSYS. However, this is
      caught under the general timeout error code EIO. I cannot see the benefit
      of exposing the REIFY waiting period to signals with such a short delay
      (40ms), while the MTU mechnism does not use the same logic. In the absence
      of any reply (wakeup() call), both reply types will wake up the task after
      the timeout period. The REIFY timeout applies to the entire representor
      group being instantiated (e.g. VFs), while the MTU timeout apples to a
      single PHY MTU change.
      Signed-off-by: NFred Lotter <frederik.lotter@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      96439889
  9. 12 11月, 2018 2 次提交
  10. 08 11月, 2018 1 次提交
  11. 12 10月, 2018 1 次提交
  12. 11 10月, 2018 1 次提交
  13. 29 7月, 2018 1 次提交
  14. 13 6月, 2018 1 次提交
  15. 25 5月, 2018 3 次提交
  16. 18 5月, 2018 1 次提交
  17. 11 5月, 2018 1 次提交
  18. 27 4月, 2018 1 次提交
  19. 13 4月, 2018 1 次提交
  20. 30 3月, 2018 1 次提交
    • 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
  21. 20 1月, 2018 2 次提交
  22. 04 1月, 2018 2 次提交
  23. 20 12月, 2017 1 次提交
  24. 17 11月, 2017 1 次提交
  25. 05 11月, 2017 1 次提交
    • D
      nfp: refactor nfp_app_reprs_set · 51ccc37d
      Dirk van der Merwe 提交于
      The criteria that reprs cannot be replaced with another new set of reprs
      has been removed. This check is not needed since the only use case that
      could exercise this at the moment, would be to modify the number of
      SRIOV VFs without first disabling them. This case is explicitly
      disallowed in any case and subsequent patches in this series
      need to be able to replace the running set of reprs.
      
      All cases where the return code used to be checked for the
      nfp_app_reprs_set function have been removed.
      As stated above, it is not possible for the current code to encounter a
      case where reprs exist and need to be replaced.
      Signed-off-by: NDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Signed-off-by: NSimon Horman <simon.horman@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      51ccc37d
  26. 27 9月, 2017 1 次提交
    • J
      nfp: offload flower vxlan endpoint MAC addresses · fd0dd1ab
      John Hurley 提交于
      Generate a list of MAC addresses of netdevs that could be used as VXLAN
      tunnel end points. Give offloaded MACs an index for storage on the NFP in
      the ranges:
      0x100-0x1ff physical port representors
      0x200-0x2ff VF port representors
      0x300-0x3ff other offloads (e.g. vxlan netdevs, ovs bridges)
      
      Assign phys and vf indexes based on unique 8 bit values in the port num.
      Maintain list of other netdevs to ensure same netdev is not offloaded
      twice and each gets a unique ID without exhausting the entries. Because
      the IDs are unique but constant for a netdev, any changes are implemented
      by overwriting the index on NFP.
      Signed-off-by: NJohn Hurley <john.hurley@netronome.com>
      Signed-off-by: NSimon Horman <simon.horman@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd0dd1ab
  27. 04 9月, 2017 1 次提交