#
8acb480e |
| 08-Mar-2024 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Have mlxsw_sp_nexthop_counter_enable() return int
In order to be able to diagnose failures in counter allocation, have the function mlxsw_sp_nexthop_counter_enable() return a
mlxsw: spectrum_router: Have mlxsw_sp_nexthop_counter_enable() return int
In order to be able to diagnose failures in counter allocation, have the function mlxsw_sp_nexthop_counter_enable() return an error code.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/e0bb5c0cc6234ade2ade1e92abac991359c3f446.1709901020.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
64f962c6 |
| 08-Mar-2024 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Rename two functions
The function mlxsw_sp_nexthop_counter_alloc() doesn't directly allocate anything, and mlxsw_sp_nexthop_counter_free() doesn't directly free. For the foll
mlxsw: spectrum_router: Rename two functions
The function mlxsw_sp_nexthop_counter_alloc() doesn't directly allocate anything, and mlxsw_sp_nexthop_counter_free() doesn't directly free. For the following patches, we will need names for functions that actually do those things. Therefore rename to mlxsw_sp_nexthop_counter_enable() and mlxsw_sp_nexthop_counter_disable() to free up the namespace.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/f59272958697a718f090f59f892d32beabcd8972.1709901020.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
4560cf40 |
| 19-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Replay IP NETDEV_UP on device deslavement
When a netdevice is removed from a bridge or a LAG, and it has an IP address, it should join the router and gain a RIF. Do that by r
mlxsw: spectrum_router: Replay IP NETDEV_UP on device deslavement
When a netdevice is removed from a bridge or a LAG, and it has an IP address, it should join the router and gain a RIF. Do that by replaying address addition event on the netdevice.
When handling deslavement of LAG or its upper from a bridge device, the replay should be done after all the lowers of the LAG have left the bridge. Thus these scenarios are handled by passing replay_deslavement of false, and by invoking, after the lowers have been processed, a new helper, mlxsw_sp_netdevice_post_lag_event(), which does the per-LAG / -upper handling, and in particular invokes the replay.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
31618b22 |
| 19-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Replay IP NETDEV_UP on device enslavement
Enslaving of front panel ports (and their uppers) to netdevices that already have uppers is currently forbidden. When this is permit
mlxsw: spectrum_router: Replay IP NETDEV_UP on device enslavement
Enslaving of front panel ports (and their uppers) to netdevices that already have uppers is currently forbidden. When this is permitted, any uppers with IP addresses need to have the NETDEV_UP inetaddr event replayed, so that any RIFs are created.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
a5b52692 |
| 13-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_switchdev: Manage RIFs on PVID change
Currently, mlxsw has several shortcomings with regards to RIF handling due to PVID changes:
- In order to cause RIF for a bridge device to be c
mlxsw: spectrum_switchdev: Manage RIFs on PVID change
Currently, mlxsw has several shortcomings with regards to RIF handling due to PVID changes:
- In order to cause RIF for a bridge device to be created, the user is expected first to set PVID, then to add an IP address. The reverse ordering is disallowed, which is not very user-friendly.
- When such bridge gets a VLAN upper whose VID was the same as the existing PVID, and this VLAN netdevice gets an IP address, a RIF is created for this netdevice. The new RIF is then assigned to the 802.1Q FID for the given VID. This results in a working configuration. However, then, when the VLAN netdevice is removed again, the RIF for the bridge itself is never reassociated to the VLAN.
- PVID cannot be changed once the bridge has uppers. Presumably this is because the driver does not manage RIFs properly in face of PVID changes. However, as the previous point shows, it is still possible to get into invalid configurations.
In this patch, add the logic necessary for creation of a RIF as a result of PVID change. Moreover, when a VLAN upper is created whose VID matches lower PVID, do not create RIF for this netdevice.
These changes obviate the need for ordering of IP address additions and PVID configuration, so stop forbidding addition of an IP address to a PVID-less bridge. Instead, bail out quietly. Also stop preventing PVID changes when the bridge has uppers.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
bdc0b78e |
| 22-Jun-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Use router.lb_crif instead of .lb_rif_index
A previous patch added a pointer to loopback CRIF to the router data structure. That makes the loopback RIF index redundant, as ev
mlxsw: spectrum_router: Use router.lb_crif instead of .lb_rif_index
A previous patch added a pointer to loopback CRIF to the router data structure. That makes the loopback RIF index redundant, as everything necessary can be derived from the CRIF. Drop the field and adjust the code accordingly.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Link: https://lore.kernel.org/r/8637bf959bc5b6c9d5184b9bd8a0cd53c5132835.1687438411.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
78126cfd |
| 22-Jun-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Maintain CRIF for fallback loopback RIF
CRIFs are generally not maintained for loopback RIFs. However, the RIF for the default VRF is used for offloading of blackhole nexthop
mlxsw: spectrum_router: Maintain CRIF for fallback loopback RIF
CRIFs are generally not maintained for loopback RIFs. However, the RIF for the default VRF is used for offloading of blackhole nexthops. Nexthops expect to have a valid CRIF. Therefore in this patch, add code to maintain CRIF for the loopback RIF as well.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Link: https://lore.kernel.org/r/7f2b2fcc98770167ed1254a904c3f7f585ba43f0.1687438411.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
4796c287 |
| 22-Jun-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Maintain a hash table of CRIFs
CRIFs are objects that mlxsw maintains for netdevices that may not have an associated RIF (i.e. they may not have been instantiated in the ASIC
mlxsw: spectrum_router: Maintain a hash table of CRIFs
CRIFs are objects that mlxsw maintains for netdevices that may not have an associated RIF (i.e. they may not have been instantiated in the ASIC), but if indeed they do not, it is quite possible they will in the future. These netdevices are candidate RIFs, hence CRIFs. Netdevices for which CRIFs are created include e.g. bridges, LAGs, or front panel ports. The idea is that next hops would be kept at CRIFs, not RIFs, and thus it would be easier to offload and unoffload the entities that have been added before the RIF was created.
In this patch, add the code for low-level CRIF maintenance: create and destroy, and keep in a table keyed by the netdevice pointer for easy recall.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Link: https://lore.kernel.org/r/186d44e399c475159da20689f2c540719f2d1ed0.1687438411.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
76962b80 |
| 12-Jun-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Add a helper specifically for joining a LAG
Currently, joining a LAG very simply means that the LAG RIF should be joined by the subport representing untagged traffic. If the
mlxsw: spectrum_router: Add a helper specifically for joining a LAG
Currently, joining a LAG very simply means that the LAG RIF should be joined by the subport representing untagged traffic. If the RIF does not exist, it does not have to be created: if the user wants there to be RIF for the LAG device, they are supposed to add an IP address, and they are supposed to do it after tha LAG becomes mlxsw upper.
We can also assume that the LAG has no uppers, otherwise the enslavement is not allowed.
In the future, these ordering dependencies should be removed. That means that joining LAG will be more complex operation, possibly involving a lazy RIF creation, and possibly joining / lazily creating RIFs for VLAN uppers of the LAG. It will be handy to have a dedicated function that handles all this. The new function mlxsw_sp_router_port_join_lag() is that.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
#
df95ae66 |
| 09-Jun-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Privatize mlxsw_sp_rif_dev()
Now that the external users of mlxsw_sp_rif_dev() have been converted in the preceding patches, make the function static.
Signed-off-by: Petr Ma
mlxsw: spectrum_router: Privatize mlxsw_sp_rif_dev()
Now that the external users of mlxsw_sp_rif_dev() have been converted in the preceding patches, make the function static.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
5374a50f |
| 09-Jun-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: Convert does-RIF-have-this-netdev queries to a dedicated helper
In a number of places, a netdevice underlying a RIF is obtained only to compare it to another pointer. In order to clean up the
mlxsw: Convert does-RIF-have-this-netdev queries to a dedicated helper
In a number of places, a netdevice underlying a RIF is obtained only to compare it to another pointer. In order to clean up the interface between the router and the other modules, add a new helper to specifically answer this question, and convert the relevant uses to this new interface.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
0255f748 |
| 09-Jun-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: Convert RIF-has-netdevice queries to a dedicated helper
In a number of places, a netdevice underlying a RIF is obtained only to check if it a NULL pointer. In order to clean up the interface
mlxsw: Convert RIF-has-netdevice queries to a dedicated helper
In a number of places, a netdevice underlying a RIF is obtained only to check if it a NULL pointer. In order to clean up the interface between the router and the other modules, add a new helper to specifically answer this question, and convert the relevant uses to this new interface.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
41b2bd20 |
| 09-Jun-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Move here inetaddr validator notifiers
The validation logic is already in the router code. Move there the notifier blocks themselves as well.
Signed-off-by: Petr Machata <pe
mlxsw: spectrum_router: Move here inetaddr validator notifiers
The validation logic is already in the router code. Move there the notifier blocks themselves as well.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
40ef76de |
| 07-Dec-2022 |
Ido Schimmel <idosch@nvidia.com> |
mlxsw: spectrum_router: Use gen_pool for RIF index allocation
Currently, each router interface (RIF) consumes one entry in the RIFs table and there are no alignment constraints. This is going to cha
mlxsw: spectrum_router: Use gen_pool for RIF index allocation
Currently, each router interface (RIF) consumes one entry in the RIFs table and there are no alignment constraints. This is going to change in subsequent patches where some RIFs will consume two table entries and their indexes will need to be aligned to the allocation size (even).
Prepare for this change by converting the RIF index allocation to use gen_pool with the 'gen_pool_first_fit_order_align' algorithm.
No Kconfig changes necessary as mlxsw already selects 'GENERIC_ALLOCATOR'.
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
fea20547 |
| 04-Jul-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Configure ingress RIF classification
Before layer 2 forwarding, the device classifies an incoming packet to a FID. The classification is done based on one of the following keys:
1. FID 2. VN
mlxsw: Configure ingress RIF classification
Before layer 2 forwarding, the device classifies an incoming packet to a FID. The classification is done based on one of the following keys:
1. FID 2. VNI (after decapsulation) 3. VID / {Port, VID}
After classification, the FID is known, but also all the attributes of the FID, such as the router interface (RIF) via which a packet that needs to be routed will ingress the router block.
In the legacy model, when a RIF was created / destroyed, it was firmware's responsibility to update it in the previously mentioned FID classification records. In the unified bridge model, this responsibility moved to software.
The third classification requires to iterate over the FID's {Port, VID} list and issue SVFA write with the correct mapping table according to the port's mode (virtual or not). We never map multiple VLANs to the same FID using VID->FID mapping, so such a mapping needs to be performed once.
When a new FID classification entry is configured and the FID already has a RIF, set the RIF as part of SVFA configuration.
The reverse needs to be done when clearing a RIF from a FID. Currently, clearing is done by issuing mlxsw_sp_fid_rif_set() with a NULL RIF pointer. Instead, introduce mlxsw_sp_fid_rif_unset().
Note that mlxsw_sp_fid_rif_set() is called after the RIF is fully operational, so it conforms to the internal requirement regarding SVFA.irif_v: "Must not be set for a non-enabled RIF".
Do not set the ingress RIF for rFIDs, as the {Port, VID}->rFID entry is configured by firmware when legacy model is used, a next patch will handle this configuration for rFIDs and unified bridge model.
Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
b9840fe0 |
| 16-Jun-2022 |
Petr Machata <petrm@nvidia.com> |
mlxsw: Keep track of number of allocated RIFs
In order to expose number of RIFs as a resource, it is going to be handy to have the number of currently-allocated RIFs as a single number. Introduce su
mlxsw: Keep track of number of allocated RIFs
In order to expose number of RIFs as a resource, it is going to be handy to have the number of currently-allocated RIFs as a single number. Introduce such.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
87c0a3c6 |
| 13-Jun-2022 |
Petr Machata <petrm@nvidia.com> |
mlxsw: Revert "Prepare for XM implementation - LPM trees"
This reverts commit 923ba95ea22d ("Merge branch 'mlxsw-spectrum-prepare-for-xm-implementation-lpm-trees'").
Signed-off-by: Petr Machata <pe
mlxsw: Revert "Prepare for XM implementation - LPM trees"
This reverts commit 923ba95ea22d ("Merge branch 'mlxsw-spectrum-prepare-for-xm-implementation-lpm-trees'").
Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
725ff532 |
| 13-Jun-2022 |
Petr Machata <petrm@nvidia.com> |
mlxsw: Revert "Prepare for XM implementation - prefix insertion and removal"
This reverts commit e7086213f7b4 ("Merge branch 'mlxsw-spectrum-prepare-for-xm-implementation-prefix-insertion-and-remova
mlxsw: Revert "Prepare for XM implementation - prefix insertion and removal"
This reverts commit e7086213f7b4 ("Merge branch 'mlxsw-spectrum-prepare-for-xm-implementation-prefix-insertion-and-removal'").
Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
6a4b02b8 |
| 13-Jun-2022 |
Petr Machata <petrm@nvidia.com> |
mlxsw: Revert "Introduce initial XM router support"
This reverts commit 75c2a8fe8e39 ("Merge branch 'mlxsw-introduce-initial-xm-router-support'").
Signed-off-by: Petr Machata <petrm@nvidia.com> Sig
mlxsw: Revert "Introduce initial XM router support"
This reverts commit 75c2a8fe8e39 ("Merge branch 'mlxsw-introduce-initial-xm-router-support'").
Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
0a27cb16 |
| 08-May-2022 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Add a dedicated notifier block
Currently all netdevice events are handled in the centralized notifier handler maintained by spectrum.c. Since a number of events are involving
mlxsw: spectrum_router: Add a dedicated notifier block
Currently all netdevice events are handled in the centralized notifier handler maintained by spectrum.c. Since a number of events are involving router code, spectrum.c needs to dispatch them to spectrum_router.c. The spectrum module therefore needs to know more about the router code than it should have, and there is are several API points through which the two modules communicate.
To simplify the notifier handlers, introduce a new notifier into the router module.
Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
cff94376 |
| 04-May-2022 |
Ido Schimmel <idosch@nvidia.com> |
mlxsw: spectrum_router: Only query neighbour activity when necessary
The driver periodically queries the device for activity of neighbour entries in order to report it to the kernel's neighbour tabl
mlxsw: spectrum_router: Only query neighbour activity when necessary
The driver periodically queries the device for activity of neighbour entries in order to report it to the kernel's neighbour table.
Avoid unnecessary activity query when no neighbours are installed. Use an atomic variable to track the number of neighbours, as it is read without any locks.
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
9834e246 |
| 02-Mar-2022 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Drop mlxsw_sp arg from counter alloc/free functions
The mlxsw_sp reference is carried by the mlxsw_sp_rif object that is passed to these functions as well. Just deduce the fo
mlxsw: spectrum_router: Drop mlxsw_sp arg from counter alloc/free functions
The mlxsw_sp reference is carried by the mlxsw_sp_rif object that is passed to these functions as well. Just deduce the former from the latter, and drop the explicit mlxsw_sp parameter. Adapt callers.
Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
605d25cd |
| 26-Oct-2021 |
Danielle Ratson <danieller@nvidia.com> |
mlxsw: spectrum_router: Add RIF MAC profiles support
Currently, mlxsw enforces that all the router interfaces (RIFs) have the same MAC prefix.
Relax this limitation by using RIF MAC profiles. Each
mlxsw: spectrum_router: Add RIF MAC profiles support
Currently, mlxsw enforces that all the router interfaces (RIFs) have the same MAC prefix.
Relax this limitation by using RIF MAC profiles. Each profile is associated with a particular MAC prefix and multiple RIFs can use the same profile. Therefore, the number of possible MAC prefixes is no longer one, but the number of profiles supported by the device.
Store the profiles in an IDR and reference count them according to the number of RIFs using them.
Associate a RIF with a profile when the RIF is created and remove the association when the RIF is deleted.
Change the association following 'NETDEV_CHANGEADDR' events, except when only one RIF is using the profile. In which case, change the MAC prefix of the profile itself instead of associating the RIF with a new profile.
Signed-off-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
59bf980d |
| 23-Sep-2021 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Take tunnel's type into account when searching underlay device
The function __mlxsw_sp_ipip_netdev_ul_dev_get() returns the underlay device that corresponds to the overlay device that it gets
mlxsw: Take tunnel's type into account when searching underlay device
The function __mlxsw_sp_ipip_netdev_ul_dev_get() returns the underlay device that corresponds to the overlay device that it gets. Currently, this function assumes that the tunnel is IPv4 GRE, because it is the only one that is supported by mlxsw driver.
This assumption will no longer be correct when IPv6 GRE support is added, resulting in wrong underlay device being returned. Instead, check 'ol_dev->type' and return the underlay device accordingly.
Move the function to spectrum_ipip.c because spectrum_router.c should not be aware to tunnel type.
Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
e3a3aae7 |
| 22-Sep-2021 |
Ido Schimmel <idosch@nvidia.com> |
mlxsw: spectrum_router: Start using new trap adjacency entry
Start using the trap adjacency entry that was added in the previous patch and remove the existing one which is no longer needed.
Note th
mlxsw: spectrum_router: Start using new trap adjacency entry
Start using the trap adjacency entry that was added in the previous patch and remove the existing one which is no longer needed.
Note that the name of the old entry was inaccurate as the entry did not discard packets, but trapped them.
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|