1. 09 6月, 2017 1 次提交
  2. 07 6月, 2017 1 次提交
  3. 05 6月, 2017 1 次提交
  4. 27 5月, 2017 6 次提交
    • I
      mlxsw: spectrum_router: Implement common RIF core · e4f3c1c1
      Ido Schimmel 提交于
      The mlxsw driver currently implements three types of RIFs. VLAN and FID
      RIFs for L3 interfaces on top of VLAN-aware and VLAN-unaware bridges
      (respectively) and Subport RIFs for all other L3 interfaces.
      
      All the RIF types follow a common configuration procedure, which only
      differs in the type-specific bits. The patch exploits this fact and
      consolidates the common code paths, thereby simplifying the code and
      making it more extensible.
      
      This work also prepares the driver for use with future ASICs, where the
      range of the Subport RIFs will be extended and their configuration
      modified accordingly. By merely implementing a new RIF operations and
      selecting it during initialization, the same driver could be re-used.
      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>
      e4f3c1c1
    • I
      mlxsw: spectrum: Implement common FID core · a1107487
      Ido Schimmel 提交于
      The device supports three types of FIDs. 802.1Q and 802.1D FIDs for
      VLAN-aware and VLAN-unaware bridges (respectively) and rFIDs to
      transport packets to the router block.
      
      The different users (e.g., bridge, router, ACLs) of the FIDs
      infrastructure need not know about the internal FIDs implementation and
      can therefore interact with it using a restricted set of exported
      functions.
      
      By encapsulating the entire FID logic and hiding it from the rest of the
      driver we get a code base that it much simpler and easier to work with
      and extend.
      
      For example, in the current Spectrum ASIC only 802.1D FIDs can be
      assigned a VNI, but future ASICs will also support 802.1Q FIDs. With
      this patch in place, support for future ASICs can be easily added by
      implementing a new FID operations according to their capabilities.
      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>
      a1107487
    • I
      mlxsw: spectrum: Replace vPorts with Port-VLAN · c57529e1
      Ido Schimmel 提交于
      As explained in the cover letter, since the introduction of the bridge
      offload in the mlxsw driver, information related to the offloaded bridge
      and bridge ports was stored in the individual port struct,
      mlxsw_sp_port.
      
      This lead to a bloated struct storing both physical properties of the
      port (e.g., autoneg status) as well as logical properties of an upper
      bridge port (e.g., learning, mrouter indication). While this might work
      well for simple devices, it proved to be hard to extend when stacked
      devices were taken into account and more advanced use-cases (e.g., IGMP
      snooping) considered.
      
      This patch removes the excess information from the above struct and
      instead stores it in more appropriate structs that represent the bridge
      port, the bridge itself and a VLAN configured on the bridge port.
      
      The membership of a port in a bridge is denoted using the Port-VLAN
      struct, which points to the bridge port and also member in the bridge
      VLAN group of the VLAN it represents. This allows us to completely
      remove the vPort abstraction and consolidate many of the code paths
      relating to VLAN-aware and unaware bridges.
      
      Note that the FID / vFID code is currently duplicated, but this will
      soon go away when the common FID core will be introduced.
      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>
      c57529e1
    • I
      mlxsw: spectrum: Change signature of FID leave function · ce95e154
      Ido Schimmel 提交于
      When a vPort is destroyed, it leaves the FID it's currently mapped to
      (if any) and drops the reference. The FID's leave function expects to
      get the vPort as its argument, but this will have to change when the
      vPort model is retired.
      
      Change the function signature to expect a Port-VLAN struct instead and
      patch the call sites accordingly.
      
      The code introduced in this patch will be removed later in the patchset,
      but this intermediary step is required in order to ease the code review.
      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>
      ce95e154
    • I
      mlxsw: spectrum: Introduce Port-VLAN structure · 31a08a52
      Ido Schimmel 提交于
      This is the first step in the transition from the vPort model to a
      unified Port-VLAN structure. The new structure is defined and created /
      destroyed upon invocation of the 8021q ndos, but it's not actually used
      throughout the code.
      
      Subsequent patches will initialize it correctly and also create /
      destroy it upon switchdev's VLAN object.
      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>
      31a08a52
    • I
      mlxsw: spectrum: Set port's mode according to FID mappings · 4aafc368
      Ido Schimmel 提交于
      We currently transition the port to "Virtual mode" upon the creation of
      its first VLAN upper, as we need to classify incoming packets to a FID
      using {Port, VID} and not only the VID.
      
      However, it's more appropriate to transition the port to this mode when
      the {Port, VID} are actually mapped to a FID. Either during the
      enslavement of the VLAN upper to a VLAN-unaware bridge or the
      configuration of a router port.
      
      Do this change now in preparation for the introduction of the FID core,
      where this operation will be encapsulated.
      
      To prevent regressions, this patch also explicitly configures an OVS
      slave to "Virtual mode". Otherwise, a packet that didn't hit an ACL rule
      could be classified to an existing FID based on a global VID-to-FID
      mapping, thus not incurring a FID mis-classification, which would
      otherwise trap the packet to the CPU to be processed by the OVS daemon.
      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>
      4aafc368
  5. 18 5月, 2017 8 次提交
  6. 01 5月, 2017 1 次提交
    • I
      mlxsw: spectrum_router: Simplify VRF enslavement · b1e45526
      Ido Schimmel 提交于
      When a netdev is enslaved to a VRF master, its router interface (RIF)
      needs to be destroyed (if exists) and a new one created using the
      corresponding virtual router (VR).
      
      >From the driver's perspective, the above is equivalent to an inetaddr
      event sent for this netdev. Therefore, when a port netdev (or its
      uppers) are enslaved to a VRF master, call the same function that
      would've been called had a NETDEV_UP was sent for this netdev in the
      inetaddr notification chain.
      
      This patch also fixes a bug when a LAG netdev with an existing RIF is
      enslaved to a VRF. Before this patch, each LAG port would drop the
      reference on the RIF, but would re-join the same one (in the wrong VR)
      soon after. With this patch, the corresponding RIF is first destroyed
      and a new one is created using the correct VR.
      
      Fixes: 7179eb5a ("mlxsw: spectrum_router: Add support for VRFs")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b1e45526
  7. 21 4月, 2017 2 次提交
  8. 26 3月, 2017 1 次提交
  9. 25 3月, 2017 4 次提交
  10. 22 3月, 2017 1 次提交
  11. 17 3月, 2017 2 次提交
  12. 13 3月, 2017 5 次提交
  13. 11 3月, 2017 4 次提交
  14. 10 3月, 2017 1 次提交
  15. 11 2月, 2017 2 次提交