1. 29 8月, 2019 2 次提交
  2. 22 8月, 2019 1 次提交
  3. 30 7月, 2019 1 次提交
    • P
      mlxsw: spectrum_ptp: Increase parsing depth when PTP is enabled · c6b36bdd
      Petr Machata 提交于
      Spectrum systems have a configurable limit on how far into the packet they
      parse. By default, the limit is 96 bytes.
      
      An IPv6 PTP packet is layered as Ethernet/IPv6/UDP (14+40+8 bytes), and
      sequence ID of a PTP event is only available 32 bytes into payload, for a
      total of 94 bytes. When an additional 802.1q header is present as
      well (such as when ptp4l is running on a VLAN port), the parsing limit is
      exceeded. Such packets are not recognized as PTP, and are not timestamped.
      
      Therefore generalize the current VXLAN-specific parsing depth setting to
      allow reference-counted requests from other modules as well. Keep it in the
      VXLAN module, because the MPRS register also configures UDP destination
      port number used for VXLAN, and is thus closely tied to the VXLAN code
      anyway.
      
      Then invoke the new interfaces from both VXLAN (in obvious places), as well
      as from PTP code, when the (global) timestamping configuration changes from
      disabled to enabled or vice versa.
      
      Fixes: 87486427 ("mlxsw: spectrum: PTP: Support SIOCGHWTSTAMP, SIOCSHWTSTAMP ioctls")
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c6b36bdd
  4. 28 7月, 2019 1 次提交
  5. 18 7月, 2019 1 次提交
    • I
      mlxsw: spectrum: Do not process learned records with a dummy FID · 577fa14d
      Ido Schimmel 提交于
      The switch periodically sends notifications about learned FDB entries.
      Among other things, the notification includes the FID (Filtering
      Identifier) and the port on which the MAC was learned.
      
      In case the driver does not have the FID defined on the relevant port,
      the following error will be periodically generated:
      
      mlxsw_spectrum2 0000:06:00.0 swp32: Failed to find a matching {Port, VID} following FDB notification
      
      This is not supposed to happen under normal conditions, but can happen
      if an ingress tc filter with a redirect action is installed on a bridged
      port. The redirect action will cause the packet's FID to be changed to
      the dummy FID and a learning notification will be emitted with this FID
      - which is not defined on the bridged port.
      
      Fix this by having the driver ignore learning notifications generated
      with the dummy FID and delete them from the device.
      
      Another option is to chain an ignore action after the redirect action
      which will cause the device to disable learning, but this means that we
      need to consume another action whenever a redirect action is used. In
      addition, the scenario described above is merely a corner case.
      
      Fixes: cedbb8b2 ("mlxsw: spectrum_flower: Set dummy FID before forward action")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: NAlex Kushnarov <alexanderk@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Tested-by: NAlex Kushnarov <alexanderk@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      577fa14d
  6. 10 7月, 2019 1 次提交
  7. 06 7月, 2019 2 次提交
  8. 02 7月, 2019 4 次提交
    • P
      mlxsw: spectrum: PTP: Support timestamping on Spectrum-1 · d92e4e6e
      Petr Machata 提交于
      On Spectrum-1, timestamps arrive through a pair of dedicated events:
      MLXSW_TRAP_ID_PTP_ING_FIFO and _EGR_FIFO. The payload delivered with
      those traps is contents of the timestamp FIFO at a given port in a given
      direction. Add a Spectrum-1-specific handler for these two events which
      decodes the timestamps and forwards them to the PTP module.
      
      Add a function that parses a packet, dispatching to ptp_classify_raw(),
      and decodes PTP message type, domain number, and sequence ID. Add a new
      mlxsw dependency on the PTP classifier.
      
      Add helpers that can store and retrieve unmatched timestamps and SKBs to
      the hash table added in a preceding patch.
      
      Add the matching code itself: upon arrival of a timestamp or a packet,
      look up the corresponding unmatched entry, and match it up. If there is
      none, add a new unmatched entry. This logic is the same on ingress as on
      egress.
      
      Packets and timestamps that never matched need to be eventually disposed
      of. A garbage collector added in a follow-up patch will take care of
      that. Since currently all this code is turned off, no crud will
      accumulate in the hash table.
      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>
      d92e4e6e
    • 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
  9. 19 6月, 2019 1 次提交
  10. 14 6月, 2019 1 次提交
  11. 23 4月, 2019 1 次提交
  12. 28 2月, 2019 1 次提交
  13. 24 2月, 2019 2 次提交
  14. 22 2月, 2019 2 次提交
  15. 09 2月, 2019 3 次提交
  16. 29 1月, 2019 1 次提交
  17. 24 1月, 2019 1 次提交
  18. 21 1月, 2019 1 次提交
  19. 21 12月, 2018 4 次提交
  20. 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
  21. 14 12月, 2018 2 次提交
  22. 12 12月, 2018 3 次提交