1. 17 Jan, 2019 28 commits
  2. 16 Jan, 2019 12 commits
    • David S. Miller's avatar
      Merge branch 'nfp-flower-improve-flower-resilience' · 159882f4
      David S. Miller authored
      Jakub Kicinski says:
      
      ====================
      nfp: flower: improve flower resilience
      
      This series contains mostly changes which improve nfp flower
      offload's resilience, but are too large or risky to push into net.
      
      Fred makes the driver waits for flower FW responses uninterruptible,
      and a little longer (~40ms).
      
      Pieter adds support for cards with multiple rule memories.
      
      John reworks the MAC offloads.  He says:
      > When potential tunnel end-point MACs are offloaded, they are assigned an
      > index. This index may be associated with a port number meaning that if a
      > packet matches an offloaded MAC address on the card, then the ingress
      > port for that MAC can also be verified. In the case of shared MACs (e.g.
      > on a linux bond) there may be situations where this index maps to only
      > one of the ports that share the MAC.
      >
      > The idea of 'global' MAC indexes are supported that bypass the check on
      > ingress port on the NFP. The patchset tracks shared MACs and assigns
      > global indexes to these. It also ensures that port based indexes are
      > re-applied if a single port becomes the only user of an offloaded MAC.
      >
      > Other patches in the set aim to tidy code without changing functionality.
      > There is also a delete offload message introduced to ensure that MACs no
      > longer in use in kernel space are removed from the firmware lookup tables.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      159882f4
    • John Hurley's avatar
      nfp: flower: enable MAC address sharing for offloadable devs · 20cce886
      John Hurley authored
      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: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20cce886
    • John Hurley's avatar
      nfp: flower: ensure MAC cleanup on address change · 13cf7103
      John Hurley authored
      It is possible to receive a MAC address change notification without the
      net device being down (e.g. when an OvS bridge is assigned the same MAC as
      a port added to it). This means that an offloaded MAC address may not be
      removed if its device gets a new address.
      
      Maintain a record of the offloaded MAC addresses for each repr and netdev
      assigned a MAC offload index. Use this to delete the (now expired) MAC if
      a change of address event occurs. Only handle change address events if the
      device is already up - if not then the netdev up event will handle it.
      Signed-off-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13cf7103
    • John Hurley's avatar
      nfp: flower: add infastructure for non-repr priv data · 05d2bee6
      John Hurley authored
      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: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      05d2bee6
    • John Hurley's avatar
      nfp: flower: ensure deletion of old offloaded MACs · 49402b0b
      John Hurley authored
      When a potential tunnel end point goes down then its MAC address should
      not be matchable on the NFP.
      
      Implement a delete message for offloaded MACs and call this on net device
      down. While at it, remove the actions on register and unregister netdev
      events. A MAC should only be offloaded if the device is up. Note that the
      netdev notifier will replay any notifications for UP devices on
      registration so NFP can still offload ports that exist before the driver
      is loaded. Similarly, devices need to go down before they can be
      unregistered so removal of offloaded MACs is only required on down events.
      Signed-off-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      49402b0b
    • John Hurley's avatar
      nfp: flower: remove list infastructure from MAC offload · 0115dcc3
      John Hurley authored
      Potential MAC destination addresses for tunnel end-points are offloaded to
      firmware. This was done by building a list of such MACs and writing to
      firmware as blocks of addresses.
      
      Simplify this code by removing the list format and sending a new message
      for each offloaded MAC.
      
      This is in preparation for delete MAC messages. There will be one delete
      flag per message so we cannot assume that this applies to all addresses
      in a list.
      Signed-off-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0115dcc3
    • John Hurley's avatar
      nfp: flower: ignore offload of VF and PF repr MAC addresses · 41da0b5e
      John Hurley authored
      Currently MAC addresses of all repr netdevs, along with selected non-NFP
      controlled netdevs, are offloaded to FW as potential tunnel end-points.
      However, the addresses of VF and PF reprs are meaningless outside of
      internal communication and it is only those of physical port reprs
      required.
      
      Modify the MAC address offload selection code to ignore VF/PF repr devs.
      Signed-off-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      41da0b5e
    • John Hurley's avatar
      nfp: flower: tidy tunnel related private data · f3b97577
      John Hurley authored
      Recent additions to the flower app private data have grouped the variables
      of a given feature into a struct and added that struct to the main private
      data struct.
      
      In keeping with this, move all tunnel related private data to their own
      struct. This has no affect on functionality but improves readability and
      maintenance of the code.
      Signed-off-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f3b97577
    • Pieter Jansen van Vuuren's avatar
      nfp: flower: support multiple memory units for filter offloads · 467322e2
      Pieter Jansen van Vuuren authored
      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: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      467322e2
    • Fred Lotter's avatar
      nfp: flower: increase cmesg reply timeout · 96439889
      Fred Lotter authored
      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: default avatarFred Lotter <frederik.lotter@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      96439889
    • Colin Ian King's avatar
      net: sungem: fix indentation, remove a tab · bdbe8cc1
      Colin Ian King authored
      The declaration of variable 'found' is one level too deep, fix this by
      removing a tab.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bdbe8cc1
    • Colin Ian King's avatar
      drivers: net: atp: fix various indentation issues · eedfb223
      Colin Ian King authored
      There are various lines that have indentation issues, fix these.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eedfb223