1. 07 4月, 2016 2 次提交
  2. 06 4月, 2016 1 次提交
  3. 12 3月, 2016 1 次提交
  4. 02 3月, 2016 3 次提交
    • I
      mlxsw: spectrum: Introduce port splitting · 18f1e70c
      Ido Schimmel 提交于
      Allow a user to split or unsplit a port using the newly introduced
      devlink ops.
      
      Once split, the original netdev is destroyed and 2 or 4 others are
      created, according to user configuration. The new ports are like any
      other port, with the sole difference of supporting a lower maximum
      speed. When unsplit, the reverse process takes place.
      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>
      18f1e70c
    • I
      mlxsw: spectrum: Store local port to module mapping during init · 558c2d5e
      Ido Schimmel 提交于
      The port netdevs are each associated with a different local port number
      in the device. These local ports are grouped into groups of 4 (e.g.
      (1-4), (5-8)) called clusters. The cluster constitutes the one of two
      possible modules they can be mapped to. This mapping is board-specific
      and done by the device's firmware during init.
      
      When splitting a port by 4, the device requires us to first unmap all
      the ports in the cluster and then map each to a single lane in the module
      associated with the port netdev used as the handle for the operation.
      This means that two port netdevs will disappear, as only 100Gb/s (4
      lanes) ports can be split and we are guaranteed to have two of these
      ((1, 3), (5, 7) etc.) in a cluster.
      
      When unsplit occurs we need to reinstantiate the two original 100Gb/s
      ports and map each to its origianl module. Therefore, during driver init
      store the initial local port to module mapping, so it can be used later
      during unsplitting.
      
      Note that a by 2 split doesn't require us to store the mapping, as we
      only need to reinstantiate one port whose module is known.
      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>
      558c2d5e
    • J
      mlxsw: Implement devlink interface · c4745500
      Jiri Pirko 提交于
      Implement newly introduced devlink interface. Add devlink port instances
      for every port and set the port types accordingly.
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c4745500
  5. 18 2月, 2016 1 次提交
  6. 29 1月, 2016 2 次提交
  7. 11 1月, 2016 3 次提交
  8. 07 1月, 2016 1 次提交
  9. 16 12月, 2015 5 次提交
    • I
      mlxsw: spectrum: Add support for VLAN devices bridging · 26f0e7fb
      Ido Schimmel 提交于
      All the member VLAN devices in a bridge need to share the same vFID.
      
      To achieve that, expand the vFID struct to include the associated bridge
      device (or lack of) and allow one to lookup a vFID based on a bridge
      device.
      
      When joining a bridge, lookup the relevant vFID or create one if none
      exists. Next, make the VLAN device use the vFID.
      
      Leaving a bridge can either occur because a user removed the VLAN device
      from a bridge or because the VLAN device was deleted by the user. In the
      latter case the bridge's teardown sequence is invoked after the hardware
      vPort is already gone. Therefore, when unlinking the VLAN device from
      the real device, check if the associated vPort is bridged and act
      accordingly. The bridge's notification will be ignored in this case.
      
      Note that bridging a VLAN interface with an ordinary port netdev is
      currently not supported, but not forbidden. This will be addressed in a
      follow-up patchset.
      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>
      26f0e7fb
    • I
      mlxsw: spectrum: Adjust FDB notifications for VLAN devices · aac78a44
      Ido Schimmel 提交于
      FDB notifications contain the FID and port (or LAG ID) on which the MAC
      was learned. In the case of the 802.1Q bridge one can easily derive the
      matching VID - as FID equals VID - and generate the appropriate
      notification for the software bridge. With VLAN devices this is no
      longer the case, as these are associated with a vFID.
      
      Solve that by converting the FID to a vFID and lookup the matching VLAN
      device. From that derive the VID and whether learning (and learning
      sync) should occur.
      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>
      aac78a44
    • I
      mlxsw: spectrum: Add another flood table for vFIDs · 19ae6124
      Ido Schimmel 提交于
      We previously used only one flood table for packets classified to vFIDs.
      However, since we are going to add support for bridges between VLAN
      interfaces (mapped to vFIDs) we need to add one more flood table.
      
      That way we can separate the flooding domain of unknown unicast traffic
      from all the rest and support flood control (as we do with the 802.1Q
      bridge).
      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>
      19ae6124
    • I
      mlxsw: spectrum: Split vFID range in two · 7f71eb46
      Ido Schimmel 提交于
      Up until now we used a 1:1 mapping - based on VID - to map a VLAN
      interface to a vFID. However, a different scheme is needed in order to
      support bridges between VLAN interfaces, as all the member interfaces -
      which can have different VIDs - need to share the same vFID.
      
      Solve that by splitting the vFID range in two:
       1. Non-bridged VLAN interfaces
       2. Bridged VLAN interfaces
      
      When a VLAN interface is created, assign it the next available vFID in
      the first range, unless one already exists for that VID or number of
      vFIDs in the range was exceeded. When interface is removed, free the
      vFID, unless other interfaces are mapped to it.
      
      To accomplish the above:
       1. Store the VID to vFID mapping in a new struct (mlxsw_sp_vfid), which
          has a global context and holds a reference count.
       2. Create a vPort (dummy in case of bridge SELF invocation) on top of
          of the physical port and hold a reference to the associated vFID.
      
      	     vfid                    vfid
      	+-------------+	        +-------------+
      	| vfid        |         | vfid        |
      	| vid         +---> ... | vid         |
      	| nr_vports   |         | nr_vports   |
      	+------+------+         +------+------+
      				       |
      	       +-----------------------+-------+
      	       |			       |
      	     vport			     vport
      	+-------------+         	+-------------+
      	| ...	      |         	| ...	      |
      	| *vfid	      +---> ... 	| *vfid	      +---> ...
      	| ...	      |         	| ...	      |
      	+------+------+         	+------+------+
      	       |                               |
      	     port			     port
      	+-------------+         	+-------------+
      	| ...         |         	| ...         |
      	| vports_list |         	| vports_list |
      	| ...         |         	| ...         |
      	+-------------+         	+-------------+
      	     swXpY			     swXpZ
      
      Next patches in the series will add the missing infrastructure for the
      second range and transfer vPorts between the two ranges according to the
      received notifications.
      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>
      7f71eb46
    • I
      mlxsw: spectrum: Allocate active VLANs only for port netdevs · bd40e9d6
      Ido Schimmel 提交于
      When adding support for bridges between VLAN interfaces, we'll introduce
      a new entity called a vPort, which is a represntation of the VLAN
      interface in the hardware.
      
      The main difference between a vPort and a physical port is that several
      FIDs can be bound to the latter, whereas only one (called a vFID) can be
      bound to the first.
      
      Therefore, it makes sense to use the same struct to represent the two,
      but to only allocate the 'active_vlans' bitmap in case of a physical
      port.
      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>
      bd40e9d6
  10. 04 12月, 2015 1 次提交
  11. 30 10月, 2015 2 次提交
  12. 16 10月, 2015 1 次提交