1. 25 Jun, 2016 18 commits
  2. 23 Jun, 2016 8 commits
  3. 22 Jun, 2016 7 commits
  4. 21 Jun, 2016 7 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