1. 11 3月, 2017 3 次提交
  2. 10 3月, 2017 1 次提交
  3. 11 2月, 2017 3 次提交
  4. 09 2月, 2017 3 次提交
  5. 07 2月, 2017 1 次提交
    • I
      mlxsw: spectrum_router: Simplify neighbour reflection · 5c8802f1
      Ido Schimmel 提交于
      Up until now we had two interfaces for neighbour related configuration:
      ndo_neigh_{construct,destroy} and NEIGH_UPDATE netevents. The ndos were
      used to add and remove neighbours from the driver's cache, whereas the
      netevent was used to reflect the neighbours into the device's tables.
      
      However, if the NUD state of a neighbour isn't NUD_VALID or if the
      neighbour is dead, then there's really no reason for us to keep it
      inside our cache. The only exception to this rule are neighbours that
      are also used for nexthops, which we periodically refresh to get them
      resolved.
      
      We can therefore eliminate the ndo entry point into the driver and
      simplify the code, making it similar to the FIB reflection, which is
      based solely on events. This also helps us avoid a locking issue, in
      which the RIF cache was traversed without proper locking during
      insertion into the neigh entry cache.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5c8802f1
  6. 04 2月, 2017 2 次提交
  7. 25 1月, 2017 1 次提交
  8. 01 11月, 2016 1 次提交
  9. 31 10月, 2016 1 次提交
  10. 24 10月, 2016 1 次提交
  11. 28 9月, 2016 1 次提交
  12. 21 9月, 2016 4 次提交
  13. 19 9月, 2016 1 次提交
  14. 14 9月, 2016 1 次提交
  15. 02 9月, 2016 1 次提交
  16. 25 8月, 2016 1 次提交
  17. 18 8月, 2016 1 次提交
  18. 25 7月, 2016 1 次提交
    • Y
      mlxsw: spectrum: Add support in matchall mirror TC offloading · 763b4b70
      Yotam Gigi 提交于
      This patch offloads port mirroring directives to hw using the matchall TC
      with action mirror. It includes both the implementation of the
      ndo_setup_tc function for the spectrum driver and the spectrum hardware
      offload configuration code.
      
      The hardware offload code is basically two new functions which are capable
      of adding and removing a new mirror ports pair. It is done using the MPAT,
      MPAR and SBIB registers:
       - A new Switch-Port Analyzer (SPAN) entry is added using MPAT to the 'to'
         port.
       - The 'to' port is bound to the SPAN entry using MPAR register.
       - In case of egress SPAN, the 'to' port gets a new internal shared
         buffer using SBIB register.
      
      In addition, a new database was added to the mlxsw_sp struct to store all
      the SPAN entries and their bound ports list. The number of supported SPAN
      entries is determined by resource query.
      Signed-off-by: NYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      763b4b70
  19. 06 7月, 2016 7 次提交
  20. 05 7月, 2016 5 次提交
    • I
      mlxsw: spectrum: Enable L3 interfaces on top of bridge devices · 99f44bb3
      Ido Schimmel 提交于
      As with the previously introduced L3 interfaces, listen to 'inetaddr'
      notifications sent for bridges devices configured on top of the port
      netdevs and create / destroy router interfaces (RIFs) accordingly.
      This also includes VLAN devices configured on top of the VLAN-aware
      bridge.
      
      The RIFs will be destroyed either when the last IP address is removed or
      when the underlying FID is is destroyed.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      99f44bb3
    • I
      mlxsw: spectrum: Configure FIDs based on bridge events · 701b186e
      Ido Schimmel 提交于
      Before introducing support for L3 interfaces on top of the VLAN-aware
      bridge we need to add some missing infrastructure.
      
      Such an interface can either be the bridge device itself or a VLAN
      device on top of it. In the first case the router interface (RIF) is
      associated with FID 1, which is created whenever the first port netdev
      joins the bridge. We currently assume the default PVID is 1 and that
      it's already created, as it seems reasonable. This can be extended in
      the future.
      
      However, in the second case it's entirely possible we've yet to create a
      matching FID. This can happen if the VLAN device was configured before
      making any bridge port member in the VLAN.
      
      Prevent such ordering problems by using the VLAN device's CHANGEUPPER
      event to configure the FID. Make the VLAN device hold a reference to the
      FID and prevent it from being destroyed even if none of the port netdevs
      is using it.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      701b186e
    • I
      mlxsw: spectrum: Unsplit the vFID range · 3ba2ebf4
      Ido Schimmel 提交于
      Previous commit deprecated the vFIDs used to get traffic to the CPU
      ('port_vfids'). Thus, we now use the vFIDs as god intended and the
      artificial split is no longer needed.
      
      Rename functions and variables to reflect that.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ba2ebf4
    • I
      mlxsw: spectrum: Introduce support for router interfaces · 99724c18
      Ido Schimmel 提交于
      Up until now we only supported bridged interfaces. Packets ingressing
      through the switch ports were either classified to FIDs (in the case of
      the VLAN-aware bridge) or vFIDs (in the case of VLAN-unaware bridges).
      The packets were then forwarded according to the FDB. Routing was done
      entirely in slowpath, by splitting the vFID range in two and using the
      lower 0.5K vFIDs as dummy bridges that simply flooded all incoming
      traffic to the CPU.
      
      Instead, allow packets to be routed in the device by creating router
      interfaces (RIFs) that will direct them to the router block.
      Specifically, the RIFs introduced here are Sub-port RIFs used for VLAN
      devices and port netdevs. Packets ingressing from the {Port / LAG ID, VID}
      with which the RIF was programmed with will be assigned to a special
      kind of FIDs called rFIDs and from there directed to the router.
      
      Create a RIF whenever the first IPv4 address was programmed on a VLAN /
      LAG / port netdev. Destroy it upon removal of the last IPv4 address.
      Receive these notifications by registering for the 'inetaddr'
      notification chain. A non-zero (10) priority is used for the
      notification block, so that RIFs will be created before routes are
      offloaded via FIB code.
      
      Note that another trigger for RIF destruction are CHANGEUPPER
      notifications causing the underlying FID's reference count to go down to
      zero. This can happen, for example, when a VLAN netdev with an IP address
      is put under bridge. While this configuration doesn't make sense it does
      cause the device and the kernel to get out of sync when the netdev is
      unbridged. We intend to address this in the future, hopefully in current
      cycle.
      
      Finally, Remove the lower 0.5K vFIDs, as they are deprecated by the RIFs,
      which will trap packets according to their DIP.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      99724c18
    • I
      mlxsw: spectrum: Edit RIF properties based on netdev events · 6e095fd4
      Ido Schimmel 提交于
      We are just about to introduce router interfaces (RIFs), but before that
      we need to be able update the device with the correct RIF attributes
      whenever they change for the netdev the RIF is backing. Two such
      attributes are MTU and MAC.
      
      The MAC is used both to set the source MAC of packets egressing from the
      RIF and also to program an FDB rule that will direct packets to the
      router block.
      
      Use the existing netdevice notification block and respond to CHANGEADDR
      and CHANGEMTU accordingly. Store both attributes in the RIF struct
      in case we need to revert to old attributes following a failed update.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e095fd4