1. 17 Jan, 2019 32 commits
  2. 16 Jan, 2019 8 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