1. 02 7月, 2019 3 次提交
    • P
      mlxsw: spectrum: PTP: Add PTP initialization / finalization · 810256ce
      Petr Machata 提交于
      Add two ptp_ops: init and fini, to initialize and finalize the PTP
      subsystem. Call as appropriate from mlxsw_sp_init() and _fini().
      
      Lay the groundwork for Spectrum-1 support. On Spectrum-1, the received
      timestamped packets and their corresponding timestamps arrive
      independently, and need to be matched up. Introduce the related data types
      and add to struct mlxsw_sp_ptp_state the hash table that will keep the
      unmatched entries.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      810256ce
    • P
      mlxsw: spectrum: PTP: Hook into packet receive path · aed4b572
      Petr Machata 提交于
      When configured, the Spectrum hardware can recognize PTP packets and
      trap them to the CPU using dedicated traps, PTP0 and PTP1.
      
      One reason to get PTP packets under dedicated traps is to have a
      separate policer suitable for the amount of PTP traffic expected when
      switch is operated as a boundary clock. For this, add two new trap
      groups, MLXSW_REG_HTGT_TRAP_GROUP_SP_PTP0 and _PTP1, and associate the
      two PTP traps with these two groups.
      
      In the driver, specifically for Spectrum-1, event PTP packets will need
      to be paired up with their timestamps. Those arrive through a different
      set of traps, added later in the patch set. To support this future use,
      introduce a new PTP op, ptp_receive.
      
      It is possible to configure which PTP messages should be trapped under
      which PTP trap. On Spectrum systems, we will use PTP0 for event
      packets (which need timestamping), and PTP1 for control packets (which
      do not). Thus configure PTP0 trap with a custom callback that defers to
      the ptp_receive op.
      
      Additionally, L2 PTP packets are actually trapped through the LLDP trap,
      not through any of the PTP traps. So treat the LLDP trap the same way as
      the PTP0 trap. Unlike PTP traps, which are currently still disabled,
      LLDP trap is active. Correspondingly, have all the implementations of
      the ptp_receive op return true, which the handler treats as a signal to
      forward the packet immediately.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aed4b572
    • P
      mlxsw: spectrum: Add support for traps specific to Spectrum-1 · dadbc6bc
      Petr Machata 提交于
      On Spectrum-1, timestamps for PTP packets are delivered through queues
      of ingress and egress timestamps. There are two event traps
      corresponding to activity on each of those queues. This mechanism is
      absent on Spectrum-2, and therefore the traps should only be registered
      on Spectrum-1.
      
      Carry a chip-specific listener array in mlxsw_sp->listeners and
      listeners_count. Register listeners from that array in
      mlxsw_sp_traps_init(). Add a new listener array for Spectrum-1 traps and
      configure the newly-added mlxsw_sp->listeners with this array.
      
      The listener array is empty for now, the events will be added in a later
      patch.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dadbc6bc
  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 2 次提交