1. 25 Jun, 2016 12 commits
  2. 23 Jun, 2016 8 commits
  3. 22 Jun, 2016 7 commits
  4. 21 Jun, 2016 13 commits
    • David S. Miller's avatar
      Merge branch 'mlxsw-next' · 0e9390eb
      David S. Miller authored
      Jiri Pirko says:
      
      ====================
      mlxsw: Preparation for IPv4 router
      
      Ido says:
      
      This series prepares the driver for IPv4 router support. The router follow-up
      patches are available at: https://github.com/jpirko/linux_mlxsw/tree/net-next_queue
      
      Patches 1-9 simplify the netdevice notification block and also add several
      checks during PRECHANGEUPPER events against topologies that aren't supported by
      the device. This will ensure L3 interfaces are only configured on top of
      valid netdevs.
      
      Patches 10-13 contain trivial changes required for the introduction of a generic
      FID struct - currently only used for vFIDs - in patch 14. Making the FID
      struct generic will allow us to easily associate the underlying FIDs with
      their L3-counterparts - Router interfaces (RIFs):
      
          FID Type        | Used by                         | RIF Type
          --------------------------------------------------------
          FID             | The VLAN-aware bridge           | VLAN
          vFID            | VLAN-unaware bridges            | FID
          rFID            | non-bridged netdevs (follow-up) | Sub-port
      
      Obligatory ASCII art to visualize the above:
      
                         A.B.C.D
                            +
                            | FID RIF
                            +
                           br0                    E.F.G.H
                            +                        +
                            |                        | VLAN RIF
                  +---------+---------+              +
                  |                   |            br1.W
                  | vFID              |              +
                  |                   |              |
       vPort    +-+-+               +-+-+            +
      swXpY.Z   |   |               |   |           br1
                +-+-+               +-+-+            +
                  |                   |     FID=W    |
                  |                   | +------------+------------+
                  |                   | |                         |
              +---+---+           +---+-+-+                   +---+---+
              |       |           |       |                   |       |
              |       |           |       |                   |       |
              |       |           |       |                   |       |
              +-------+           +-------+                   +-------+
                swXpY
      
      Patches 15-16 further generalize the struct by exploiting the fact that the
      FID is a shared resource among ports. Each FID type is assigned a 'leave'
      function that is invoked based on CHANGEUPPER events and takes care of the
      necessary clean-up.
      
      Patches 17-22 build upon the previous patches and use the FID struct for the
      VLAN-aware bridge and take care of cleaning up FID resources in the 'leave'
      functions. For now, these are only FDB records, but later on we'll have to
      remove the RIFs associated with these FIDs, which will in turn take care of
      routes and neighbours clean-up.
      
      The last patch adds debug prints that proved very useful during the
      development of this series.
      
      Tested with the existing L2 recipes:
      https://github.com/jpirko/lnst/tree/master/recipes/switchdev
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0e9390eb
    • Ido Schimmel's avatar
      mlxsw: spectrum: Add debug prints · 22305378
      Ido Schimmel authored
      For debug purposes, it's useful to know the order in which the driver
      responds to changes in the topology of its upper devices.
      
      Add debug prints to signal these events.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      22305378
    • Ido Schimmel's avatar
      mlxsw: spectrum: Free resources upon vPort destruction · 1c800759
      Ido Schimmel authored
      There are situations in which a vPort is destroyed while still holding
      references to device's resources such as FIDs and FDB records. This can
      happen, for example, when a VLAN device is deleted while still being
      bridged.
      
      Instead of trying to make sure vPort destruction is invoked when it no
      longer uses device's resources, just free them upon destruction. This
      simplifies the code, as we no longer need to take different situations
      into account when events are received - cleanup is taken care of in one
      place.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c800759
    • Ido Schimmel's avatar
      mlxsw: spectrum: Refactor FDB flushing logic · fe3f6d14
      Ido Schimmel authored
      FDB entries are learned using {Port / LAG ID, FID} and therefore should
      be flushed whenever a port (vPort) leaves its FID (vFID).
      
      However, when the bridge port is a LAG device (or a VLAN device on top),
      then FDB flushing is conditional. Ports removed from such LAG
      configurations must not trigger flushing, as other ports might still be
      members in the LAG and therefore the bridge port is still active.
      
      The decision whether to flush or not was previously computed in the
      netdevice notification block, but in order to flush the entries when a
      port leaves its FID this decision should be computed there.
      
      Strip the notification block from this logic and instead move it to one
      FDB flushing function that is invoked from both the FID / vFID leave
      functions.
      
      When port isn't member in LAG, FDB flushing should always occur.
      Otherwise, it should occur only when the last port (vPort) member in the
      LAG leaves the FID (vFID).
      
      This will allow us - in the next patch - to simplify the cleanup code
      paths that are hit whenever the topology above the port netdevs changes.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe3f6d14
    • Ido Schimmel's avatar
      mlxsw: spectrum: Don't count on FID being present · 56918b6b
      Ido Schimmel authored
      Not all vPorts will have FIDs assigned to them, so make sure functions
      first test for FID presence.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      56918b6b
    • Ido Schimmel's avatar
      mlxsw: spectrum: Add FID get / set functions · 41b996cc
      Ido Schimmel authored
      As previously explained, not all vPorts will be assigned FIDs, so instead
      of returning the FID index of a vPort, return a pointer to its FID
      struct. This will allow us to know whether it's legal to access the
      vPort's FID parameters such as index and device.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      41b996cc
    • Ido Schimmel's avatar
      mlxsw: spectrum: Check if port is vPort using its VID · 6381b3a8
      Ido Schimmel authored
      When L3 interfaces will be introduced a vPort won't necessarily have a
      FID assigned to it. This can happen if it's not member in a bridge (in
      which case it's assigned a vFID) or doesn't have an IP address (in which
      case it's assigned an rFID).
      
      Therefore, instead check the VID parameter to test whether a port is a
      vPort or not.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6381b3a8
    • Ido Schimmel's avatar
      mlxsw: spectrum: Use per-FID struct for the VLAN-aware bridge · 14d39461
      Ido Schimmel authored
      In a very similar way to the vFIDs, make the first 4K FIDs - used in the
      VLAN-aware bridge - use the new FID struct.
      
      Upon first use of the FID by any of the ports do the following:
      
      1) Create the FID
      2) Setup a matching flooding entry
      3) Create a mapping for the FID
      
      Unlike vFIDs, upon creation of a FID we always create a global
      VID-to-FID mapping, so that ports without upper vPorts can use it
      instead of creating an explicit {Port, VID} to FID mapping.
      
      When a port leaves a FID the reverse is performed. Whenever the FID's
      reference count reaches zero the FID is deleted along with the global
      mapping.
      
      The per-FID struct will later allow us to configure L3 interfaces on top
      of the VLAN-aware bridge.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      14d39461
    • Ido Schimmel's avatar
      37286d25
    • Ido Schimmel's avatar
      mlxsw: spectrum: Use join / leave functions for vFID operations · 0355b59f
      Ido Schimmel authored
      When a vPort is created or when it joins a bridge we always do the same
      set of operations:
      
      1) Create the vFID, if not already created
      2) Setup flooding for the vFID
      3) Map the {Port, VID} to the vFID
      
      When a vPort is destroyed or when it leaves a bridge the reverse is
      performed.
      
      Encapsulate the above in join / leave functions and simplify the code.
      FIDs and rFIDs will use a similar set of functions.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0355b59f
    • Ido Schimmel's avatar
      mlxsw: spectrum: Make vFID struct generic · d0ec875a
      Ido Schimmel authored
      Up until now we had a dedicated struct only for vFIDs, but before
      introducing support for L3 interfaces we need to make it generic and
      use it for all three types of FIDs:
      
      1) FIDs - 0..4K-1, used for the VLAN-aware bridge
      2) vFIDs - 4K..15K-1, used for VLAN-unaware bridges
      3) rFIDs - 15K..16K-1, used to direct traffic to / from the router in
      the device. Will be introduced later in the series.
      
      The three types of L3 interfaces - Router InterFaces, RIFs - that will
      be introduced correspond to the three types of FIDs and are configured
      using them. Therefore, we'll need to store the links between them as
      well as a reference count on the underlying FID, so that the
      corresponding RIF will be destroyed when it reaches zero.
      
      Note that the lower 0.5K vFIDs are currently used for for non-bridged
      netdevs, so that traffic could be flooded to the CPU port. However, when
      rFIDs will be introduced we'll no longer need these and they too will be
      used for VLAN-unaware bridges.
      
      Make the vFID struct generic by renaming it and some of its fields. FIDs
      will be converted to use it later in the series.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0ec875a
    • Ido Schimmel's avatar
      mlxsw: spectrum: Use FID instead of vFID to setup flooding · e6060027
      Ido Schimmel authored
      Use a FID index instead of vFID and ease the transition towards a
      generic FID struct.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6060027
    • Ido Schimmel's avatar
      mlxsw: spectrum: Create a function to map vPort's FID · 9c4d4423
      Ido Schimmel authored
      A FID used by a vPort (vFID, but also rFID later in the series) is
      always mapped using {Port, VID} and not only VID as with the 4K FIDs of
      the VLAN-aware bridge.
      
      Instead of specifying all the arguments each time, just wrap this
      operation using a dedicated function and simplify the code.
      
      As before, the function takes FID as its argument in preparation for a
      generic FID struct.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9c4d4423