lwn.git/drivers/net/ethernet/mellanox/mlxsw/trap.h, branch docs-fixes

mlxsw: spectrum: Forward packets with an IPv4 link-local source IP

2025-08-15T17:44:48+00:00

By default, the device does not forward IPv4 packets with a link-local source IP (i.e., 169.254.0.0/16). This behavior does not align with the kernel which does forward them. Fix by instructing the device to forward such packets instead of dropping them. Fixes: ca360db4b825 ("mlxsw: spectrum: Disable DIP_LINK_LOCAL check in hardware pipeline") Reported-by: Zoey Mertes Signed-off-by: Ido Schimmel Reviewed-by: Petr Machata Signed-off-by: Petr Machata Link: https://patch.msgid.link/6721e6b2c96feb80269e72ce8d0b426e2f32d99c.1755174341.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski

mlxsw: Trap ARP packets at layer 2 instead of layer 3

2025-03-24T22:09:30+00:00

Next patch will set the same hardware domain for all bridge ports, including VXLAN, to prevent packets from being forwarded by software when they were already forwarded by hardware. ARP packets are not flooded by hardware to VXLAN, so software should handle such flooding. When hardware domain of VXLAN device will be changed, ARP packets which are trapped and marked with offload_fwd_mark will not be flooded to VXLAN also in software, which will break VXLAN traffic. To prevent such breaking, trap ARP packets at layer 2 and don't mark them as L2-forwarded in hardware, then flooding ARP packets will be done only in software, and VXLAN will send ARP packets. Remove NVE_ENCAP_ARP which is no longer needed, as now ARP packets are trapped when they enter the device. Signed-off-by: Amit Cohen Reviewed-by: Petr Machata Reviewed-by: Ido Schimmel Signed-off-by: Petr Machata Reviewed-by: Simon Horman Link: https://patch.msgid.link/b2a2cc607a1f4cb96c10bd3b0b0244ba3117fd2e.1742224300.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski

mlxsw: spectrum_trap: Register 802.1X packet traps with devlink

2022-11-10T03:06:14+00:00

Register the previously added packet traps with devlink. This allows user space to tune their policers and in the case of the locked port trap, user space can set its action to "trap" in order to gain visibility into packets that were discarded by the device due to the locked port check failure. Signed-off-by: Ido Schimmel Reviewed-by: Petr Machata Signed-off-by: Petr Machata Signed-off-by: Jakub Kicinski

mlxsw: Trap ARP packets at layer 3 instead of layer 2

2022-06-17T09:31:33+00:00

Currently, the traps 'ARP_REQUEST' and 'ARP_RESPONSE' occur at layer 2. To allow the packets to be flooded, they are configured with the action 'MIRROR_TO_CPU' which means that the CPU receives a replica of the packet. Today, Spectrum ASICs also support trapping ARP packets at layer 3. This behavior is better, then the packets can just be trapped and there is no need to mirror them. An additional motivation is that using the traps at layer 2, the ARP packets are dropped in the router as they do not have an IP header, then they are counted as error packets, which might confuse users. Add the relevant traps for layer 3 and use them instead of the existing traps. There is no visible change to user space. Signed-off-by: Amit Cohen Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller

mlxsw: core_linecards: Add line card objects and implement provisioning

2022-04-18T10:00:19+00:00

Introduce objects for line cards and an infrastructure around that. Use devlink_linecard_create/destroy() to register the line card with devlink core. Implement provisioning ops with a list of supported line cards. Signed-off-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller

mlxsw: spectrum: Introduce port mapping change event processing

2022-04-18T10:00:19+00:00

Register PMLPE trap and process the port mapping changes delivered by it by creating related ports. Note that this happens after provisioning. The INI of the linecard is processed and merged by FW. PMLPE is generated for each port. Process this mapping change. Layout of PMLPE is the same as layout of PMLP. Signed-off-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller

mlxsw: spectrum_router: Use different trap identifier for unresolved nexthops

2020-11-24T20:14:55+00:00

Unresolved nexthops are currently written to the adjacency table with a discard action. Packets hitting such entries are trapped to the CPU via the 'DISCARD_ROUTER3' trap which can be enabled or disabled on demand, but is always enabled in order to ensure the kernel can resolve the unresolved neighbours. This trap will be needed for blackhole nexthops support. Therefore, move unresolved nexthops to explicitly program the adjacency entries with a trap action and a different trap identifier, 'RTR_EGRESS0'. Signed-off-by: Ido Schimmel Reviewed-by: Jiri Pirko Signed-off-by: Jakub Kicinski

mlxsw: Update module's settings when module is plugged in

2020-09-27T20:27:01+00:00

Module temperature warning events are enabled for modules that have a temperature sensor and configured according to the temperature thresholds queried from the module. When a module is unplugged we are guaranteed not to get temperature warning events. However, when a module is plugged in we need to potentially update its current settings (i.e., event enablement and thresholds). Register to port module plug/unplug events and update module's settings upon plug in events. Signed-off-by: Amit Cohen Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller

mlxsw: Update transceiver_overheat counter according to MTWE

2020-09-27T20:27:00+00:00

MTWE (Management Temperature Warning Event) is triggered when module's temperature is higher than its threshold. Register for MTWE events and increase the module's overheat counter when its corresponding sensor goes above the configured threshold. Signed-off-by: Amit Cohen Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller

mlxsw: core: Introduce fw_fatal health reporter

2020-09-15T22:57:16+00:00

Introduce devlink health reporter to report FW fatal events. Implement the event listener using MFDE trap and enable the events to be propagated using MFGD register configuration. Signed-off-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller