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