1. 02 7月, 2019 1 次提交
  2. 19 6月, 2019 1 次提交
  3. 14 6月, 2019 1 次提交
  4. 23 4月, 2019 1 次提交
  5. 28 2月, 2019 1 次提交
  6. 24 2月, 2019 2 次提交
  7. 22 2月, 2019 2 次提交
  8. 09 2月, 2019 3 次提交
  9. 29 1月, 2019 1 次提交
  10. 24 1月, 2019 1 次提交
  11. 21 1月, 2019 1 次提交
  12. 21 12月, 2018 4 次提交
  13. 20 12月, 2018 4 次提交
    • I
      mlxsw: spectrum_router: Make RIF deletion more robust · 965fa8e6
      Ido Schimmel 提交于
      In the past we had multiple instances where RIFs were not properly
      deleted.
      
      One of the reasons for leaking a RIF was that at the time when IP
      addresses were flushed from the respective netdev (prompting the
      destruction of the RIF), the netdev was no longer a mlxsw upper. This
      caused the inet{,6}addr notification blocks to ignore the NETDEV_DOWN
      event and leak the RIF.
      
      Instead of checking whether the netdev is our upper when an IP address
      is removed, we can instead check if the netdev has a RIF configured.
      
      To look up a RIF we need to access mlxsw private data, so the patch
      stores the notification blocks inside a mlxsw struct. This then allows
      us to use container_of() and extract the required private data.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      965fa8e6
    • I
      mlxsw: spectrum: Remove reference count from VLAN entries · 635c8c8b
      Ido Schimmel 提交于
      Commit b3529af6 ("spectrum: Reference count VLAN entries") started
      reference counting port-VLAN entries in a similar fashion to the 8021q
      driver.
      
      However, this is not actually needed and only complicates things.
      Instead, the driver should forbid the creation of a VLAN on a port if
      this VLAN already exists. This would also solve the issue fixed by the
      mentioned commit.
      
      Therefore, remove the get()/put() API and use create()/destroy()
      instead.
      
      One place that needs special attention is VLAN addition in a VLAN-aware
      bridge via switchdev operations. In case the VLAN flags (e.g., 'pvid')
      are toggled, then the VLAN entry already exists. To prevent the driver
      from wrongly returning EEXIST, the driver is changed to check in the
      prepare phase whether the entry already exists and only returns an error
      in case it is not associated with the correct bridge port.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      635c8c8b
    • I
      mlxsw: spectrum_fid: Remove unused function · f1d7c33d
      Ido Schimmel 提交于
      This function is no longer used. Remove it.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f1d7c33d
    • I
      mlxsw: spectrum_router: Do not destroy RIFs based on FID's reference count · 32fd4b49
      Ido Schimmel 提交于
      Currently, when a RIF is constructed on top of a FID, the RIF increments
      the FID's reference count and the RIF is destroyed when the FID's
      reference count drops to 1. This effectively means that when no local
      ports are member in the FID, the FID is destroyed regardless if the
      router port is a member in the FID or not.
      
      The above can lead to the unexpected behavior in which routes using a
      VLAN interface as their nexthop device are no longer offloaded after the
      last local port leaves the corresponding VLAN (FID).
      
      Example:
      # ip -4 route show dev br0.10
      192.0.2.0/24 proto kernel scope link src 192.0.2.1 offload
      # bridge vlan del vid 10 dev swp3
      # ip -4 route show dev br0.10
      192.0.2.0/24 proto kernel scope link src 192.0.2.1
      
      After the patch, the route is offloaded before and after the VLAN is
      removed from local port 'swp3', as the RIF corresponding to 'br0.10'
      continues to exists.
      
      In order to remove RIFs' reliance on the underlying FID's reference
      count, we need to add a reference count to sub-port RIFs, which are RIFs
      that correspond to physical ports and their uppers (e.g., LAG devices).
      
      In this case, each {Port, VID} ('struct mlxsw_sp_port_vlan') needs to
      hold a reference on the RIF. For example:
      
                             bond0.10
                                |
                              bond0
                                |
                            +-------+
                            |       |
                          swp1    swp2
      
      Both {Port 1, VID 10} and {Port 2, VID 10} will hold a reference on the
      RIF corresponding to 'bond0.10'. When the last reference is dropped, the
      RIF will be destroyed.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32fd4b49
  14. 14 12月, 2018 2 次提交
  15. 12 12月, 2018 3 次提交
  16. 08 12月, 2018 3 次提交
  17. 01 12月, 2018 4 次提交
  18. 28 11月, 2018 1 次提交
  19. 22 11月, 2018 3 次提交
  20. 18 10月, 2018 1 次提交
    • I
      mlxsw: spectrum: Enable VxLAN enslavement to bridges · 1c30d183
      Ido Schimmel 提交于
      Enslavement of VxLAN devices to offloaded bridges was never forbidden by
      mlxsw, but this patch makes sure the required configuration is performed
      in order to allow VxLAN encapsulation and decapsulation to take place in
      the device.
      
      The patch handles both the case where a VxLAN device is enslaved to an
      already offloaded bridge and the case where the first mlxsw port is
      enslaved to a bridge that already has VxLAN device configured.
      
      Invalid configurations are sanitized and an error string is returned via
      extack.
      
      Since encapsulation and decapsulation do not occur when the VxLAN device
      is down, the driver makes sure to enable / disable these functionalities
      based on NETDEV_PRE_UP and NETDEV_DOWN events.
      
      Note that NETDEV_PRE_UP is used in favor of NETDEV_UP, as the former
      allows to veto the operation, if necessary.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c30d183