1. 21 9月, 2017 3 次提交
  2. 23 8月, 2017 1 次提交
  3. 05 8月, 2017 2 次提交
    • I
      mlxsw: spectrum_switchdev: Release multicast groups during fini · 852cfeed
      Ido Schimmel 提交于
      Each multicast group (MID) stores a bitmap of ports to which a packet
      should be forwarded to in case an MDB entry associated with the MID is
      hit.
      
      Since the initial introduction of IGMP snooping in commit 3a49b4fd
      ("mlxsw: Adding layer 2 multicast support") the driver didn't correctly
      free these multicast groups upon ungraceful situations such as the
      removal of the upper bridge device or module removal.
      
      The correct way to fix this is to associate each MID with the bridge
      ports member in it and then drop the reference in case the bridge port
      is destroyed, but this will result in a lot more code and will be fixed
      in net-next.
      
      For now, upon module removal, traverse the MID list and release each
      one.
      
      Fixes: 3a49b4fd ("mlxsw: Adding layer 2 multicast support")
      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>
      852cfeed
    • I
      mlxsw: spectrum_switchdev: Don't warn about valid situations · 17b334a8
      Ido Schimmel 提交于
      Some operations in the bridge driver such as MDB deletion are preformed
      in an atomic context and thus deferred to a process context by the
      switchdev infrastructure.
      
      Therefore, by the time the operation is performed by the underlying
      device driver it's possible the bridge port context is already gone.
      This is especially true for removal flows, but theoretically can also be
      invoked during addition.
      
      Remove the warnings in such situations and return normally.
      
      Fixes: c57529e1 ("mlxsw: spectrum: Replace vPorts with Port-VLAN")
      Fixes: 3922285d ("net: bridge: Add support for offloading port attributes")
      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>
      17b334a8
  4. 12 7月, 2017 2 次提交
  5. 09 6月, 2017 7 次提交
  6. 27 5月, 2017 3 次提交
    • 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: 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
  7. 18 5月, 2017 7 次提交
  8. 21 4月, 2017 1 次提交
  9. 25 3月, 2017 1 次提交
  10. 22 3月, 2017 1 次提交
  11. 11 2月, 2017 6 次提交
  12. 01 11月, 2016 1 次提交
  13. 24 10月, 2016 1 次提交
  14. 28 9月, 2016 1 次提交
  15. 21 9月, 2016 1 次提交
  16. 02 9月, 2016 2 次提交