Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15 |
|
#
99a9e7fb |
| 26-Jan-2024 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Use refcount_t for reference counting
[ Upstream commit 1267f7223bec186dc26ef4e6075496c6217355de ]
mlxsw driver uses 'unsigned int' for reference counters in several structures. Instead, use
mlxsw: Use refcount_t for reference counting
[ Upstream commit 1267f7223bec186dc26ef4e6075496c6217355de ]
mlxsw driver uses 'unsigned int' for reference counters in several structures. Instead, use refcount_t type which allows us to catch overflow and underflow issues. Change the type of the counters and use the appropriate API.
Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Stable-dep-of: 627f9c1bb882 ("mlxsw: spectrum_acl_tcam: Fix race in region ID allocation") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15 |
|
#
99a9e7fb |
| 26-Jan-2024 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Use refcount_t for reference counting
[ Upstream commit 1267f7223bec186dc26ef4e6075496c6217355de ]
mlxsw driver uses 'unsigned int' for reference counters in several structures. Instead, use
mlxsw: Use refcount_t for reference counting
[ Upstream commit 1267f7223bec186dc26ef4e6075496c6217355de ]
mlxsw driver uses 'unsigned int' for reference counters in several structures. Instead, use refcount_t type which allows us to catch overflow and underflow issues. Change the type of the counters and use the appropriate API.
Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Stable-dep-of: 627f9c1bb882 ("mlxsw: spectrum_acl_tcam: Fix race in region ID allocation") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15 |
|
#
99a9e7fb |
| 26-Jan-2024 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Use refcount_t for reference counting
[ Upstream commit 1267f7223bec186dc26ef4e6075496c6217355de ]
mlxsw driver uses 'unsigned int' for reference counters in several structures. Instead, use
mlxsw: Use refcount_t for reference counting
[ Upstream commit 1267f7223bec186dc26ef4e6075496c6217355de ]
mlxsw driver uses 'unsigned int' for reference counters in several structures. Instead, use refcount_t type which allows us to catch overflow and underflow issues. Change the type of the counters and use the appropriate API.
Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Stable-dep-of: 627f9c1bb882 ("mlxsw: spectrum_acl_tcam: Fix race in region ID allocation") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.14, v6.6.13 |
|
#
7788f557 |
| 17-Jan-2024 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Register netdevice notifier before nexthop
[ Upstream commit 62bef63646c194e0f82b40304a0f2d060b28687b ]
If there are IPIP nexthops at the time when the driver is loaded (or
mlxsw: spectrum_router: Register netdevice notifier before nexthop
[ Upstream commit 62bef63646c194e0f82b40304a0f2d060b28687b ]
If there are IPIP nexthops at the time when the driver is loaded (or the devlink instance reloaded), the driver looks up the corresponding IPIP entry. But IPIP entries are only created as a result of netdevice notifications. Since the netdevice notifier is registered after the nexthop notifier, mlxsw_sp_nexthop_type_init() never finds the IPIP entry, registers the nexthop MLXSW_SP_NEXTHOP_TYPE_ETH, and fails to assign a CRIF to the nexthop. Later on when the CRIF is necessary, the WARN_ON in mlxsw_sp_nexthop_rif() triggers, causing the splat [1].
In order to fix the issue, reorder the netdevice notifier to be registered before the nexthop one.
[1] (edited for clarity):
WARNING: CPU: 1 PID: 1364 at drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3245 mlxsw_sp_nexthop_rif (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3246 (discriminator 1)) mlxsw_spectrum Hardware name: Mellanox Technologies Ltd. MSN4410/VMOD0010, BIOS 5.11 01/06/2019 Call Trace: ? mlxsw_sp_nexthop_rif (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3246 (discriminator 1)) mlxsw_spectrum __mlxsw_sp_nexthop_eth_update (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3637) mlxsw_spectrum mlxsw_sp_nexthop_update (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3679 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3727) mlxsw_spectrum mlxsw_sp_nexthop_group_update (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3757) mlxsw_spectrum mlxsw_sp_nexthop_group_refresh (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:4112) mlxsw_spectrum mlxsw_sp_nexthop_obj_event (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5118 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5191 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5315 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5500) mlxsw_spectrum nexthops_dump (net/ipv4/nexthop.c:217 net/ipv4/nexthop.c:440 net/ipv4/nexthop.c:3609) register_nexthop_notifier (net/ipv4/nexthop.c:3624) mlxsw_sp_router_init (drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:11486) mlxsw_spectrum mlxsw_sp_init (drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3267) mlxsw_spectrum __mlxsw_core_bus_device_register (drivers/net/ethernet/mellanox/mlxsw/core.c:2202) mlxsw_core mlxsw_devlink_core_bus_device_reload_up (drivers/net/ethernet/mellanox/mlxsw/core.c:2265 drivers/net/ethernet/mellanox/mlxsw/core.c:1603) mlxsw_core devlink_reload (net/devlink/dev.c:314 net/devlink/dev.c:475) [...]
Fixes: 9464a3d68ea9 ("mlxsw: spectrum_router: Track next hops at CRIFs") Reported-by: Maksym Yaremchuk <maksymy@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Link: https://lore.kernel.org/r/74edb8d45d004e8d8f5318eede6ccc3d786d8ba9.1705502064.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43 |
|
#
cb211620 |
| 27-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: IPv6 events: Use tracker helpers to hold & put netdevices
Using the tracking helpers makes it easier to debug netdevice refcount imbalances when CONFIG_NET_DEV_REFCNT_TRACKER
mlxsw: spectrum_router: IPv6 events: Use tracker helpers to hold & put netdevices
Using the tracking helpers makes it easier to debug netdevice refcount imbalances when CONFIG_NET_DEV_REFCNT_TRACKER is enabled.
Convert dev_hold() / dev_put() to netdev_hold() / netdev_put() in the router code that deals with IPv6 address events.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/f0af6ad4722b4ca6e598fd4fda8311a3041651ec.1690471775.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
d0e0e880 |
| 27-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: RIF: Use tracker helpers to hold & put netdevices
Using the tracking helpers makes it easier to debug netdevice refcount imbalances when CONFIG_NET_DEV_REFCNT_TRACKER is enab
mlxsw: spectrum_router: RIF: Use tracker helpers to hold & put netdevices
Using the tracking helpers makes it easier to debug netdevice refcount imbalances when CONFIG_NET_DEV_REFCNT_TRACKER is enabled.
Convert dev_hold() / dev_put() to netdev_hold() / netdev_put() in the router code that deals with RIF allocation.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/8b7701a7b439ac268e4be4040eff99d01e27ae47.1690471775.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
b17b2d57 |
| 27-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: hw_stats: Use tracker helpers to hold & put netdevices
Using the tracking helpers makes it easier to debug netdevice refcount imbalances when CONFIG_NET_DEV_REFCNT_TRACKER is
mlxsw: spectrum_router: hw_stats: Use tracker helpers to hold & put netdevices
Using the tracking helpers makes it easier to debug netdevice refcount imbalances when CONFIG_NET_DEV_REFCNT_TRACKER is enabled.
Convert dev_hold() / dev_put() to netdev_hold() / netdev_put() in the router code that deals with hw_stats events.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/b972314cfef4f4c24e66e60d13cffa5d606d1bf3.1690471774.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
deeaa371 |
| 27-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: FIB: Use tracker helpers to hold & put netdevices
Using the tracking helpers makes it easier to debug netdevice refcount imbalances when CONFIG_NET_DEV_REFCNT_TRACKER is enab
mlxsw: spectrum_router: FIB: Use tracker helpers to hold & put netdevices
Using the tracking helpers makes it easier to debug netdevice refcount imbalances when CONFIG_NET_DEV_REFCNT_TRACKER is enabled.
Convert dev_hold() / dev_put() to netdev_hold() / netdev_put() in the router code that deals with FIB events.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/5221a92e751c40447c55959f622267ccc999ed04.1690471774.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
Revision tags: v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
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 ...
|
#
8fdb09a7 |
| 19-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Replay neighbours when RIF is made
As neighbours are created, mlxsw is involved through the netevent notifications. When at the time there is no RIF for a given neighbour, th
mlxsw: spectrum_router: Replay neighbours when RIF is made
As neighbours are created, mlxsw is involved through the netevent notifications. When at the time there is no RIF for a given neighbour, the notification is not acted upon. When the RIF is later created, these outstanding neighbours are left unoffloaded and cause traffic to go through the SW datapath.
In order to fix this issue, as a RIF is created, walk the ARP and ND tables and find neighbours for the netdevice that represents the RIF. Then schedule neighbour work for them, allowing them to be offloaded.
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 ...
|
#
49c3a615 |
| 19-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Replay MACVLANs when RIF is made
If IP address is added to a MACVLAN netdevice, the effect is of configuring VRRP on the RIF for the netdevice linked to the MACVLAN. Because
mlxsw: spectrum_router: Replay MACVLANs when RIF is made
If IP address is added to a MACVLAN netdevice, the effect is of configuring VRRP on the RIF for the netdevice linked to the MACVLAN. Because the MACVLAN offload is tied to existence of a RIF at the linked netdevice, adding a MACVLAN is currently not allowed until a RIF is present.
If this requirement stays, it will never be possible to attach a first port into a topology that involves a MACVLAN. Thus topologies would need to be built in a certain order, which is impractical.
Additionally, IP address removal, which leads to disappearance of the RIF that the MACVLAN depends on, cannot be vetoed. Thus even as things stand now it is possible to get to a state where a MACVLAN netdevice exists without a RIF, despite having mlxsw lowers. And once the MACVLAN is un-offloaded due to RIF getting destroyed, recreating the RIF does not bring it back.
In this patch, accept that MACVLAN can be created out of order and support that use case.
One option would seem to be to simply recognize MACVLAN netdevices as "interesting", and let the existing replay mechanisms take care of the offload. However, that does not address the necessity to reoffload MACVLAN once a RIF is created.
Thus add a new replay hook, symmetrical to mlxsw_sp_rif_macvlan_flush(), called mlxsw_sp_rif_macvlan_replay(), which instead of unwinding the existing offloads, applies the configuration as if the netdevice were created just now.
Additionally, remove all vetoes and warning messages that checked for presence of a RIF at the linked device.
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 ...
|
#
cfc01a92 |
| 19-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Offload ethernet nexthops when RIF is made
As RIF is created, refresh each netxhop group tracked at the CRIF for which the RIF was created.
Note that nothing needs to be don
mlxsw: spectrum_router: Offload ethernet nexthops when RIF is made
As RIF is created, refresh each netxhop group tracked at the CRIF for which the RIF was created.
Note that nothing needs to be done for IPIP nexthops. The RIF for these is either available from the get-go, or will never be available, so no after the fact offloading needs to be done.
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 ...
|
#
ef59713c |
| 19-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Join RIFs of LAG upper VLANs
In the following patches, the requirement that ports be only enslaved to masters without uppers, is going to be relaxed. It will therefore be nec
mlxsw: spectrum_router: Join RIFs of LAG upper VLANs
In the following patches, the requirement that ports be only enslaved to masters without uppers, is going to be relaxed. It will therefore be necessary to join not only RIF for the immediate LAG, as is currently the case, but also RIFs for VLAN netdevices upper to the LAG.
In this patch, extend mlxsw_sp_netdevice_router_join_lag() to walk the uppers of a LAG being joined, and also join any VLAN ones.
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 ...
|
#
96c3e45c |
| 19-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Extract a helper to schedule neighbour work
This will come in handy for neighbour replay.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <daniel
mlxsw: spectrum_router: Extract a helper to schedule neighbour work
This will come in handy for neighbour 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 ...
|
#
6bbc9ca6 |
| 19-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Allow address handlers to run on bridge ports
Currently the IP address event handlers bail out when the event is related to a netdevice that is a bridge port or a member of a
mlxsw: spectrum_router: Allow address handlers to run on bridge ports
Currently the IP address event handlers bail out when the event is related to a netdevice that is a bridge port or a member of a LAG. In order to create a RIF when a bridged or LAG'd port is unenslaved, these event handlers will be replayed. However, at the point in time when the NETDEV_CHANGEUPPER event is delivered, informing of the loss of enslavement, the port is still formally enslaved.
In order for the operation to have any effect, these handlers need an extra parameter to indicate that the check for bridge or LAG membership should not be done. In this patch, add an argument "nomaster" to several event handlers.
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 ...
|
#
3430f2cf |
| 13-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: mlxsw_sp_inetaddr_bridge_event: Add an argument
For purposes of replay, mlxsw_sp_inetaddr_bridge_event() will need to make decisions based on the proposed value of PVID. Quer
mlxsw: spectrum_router: mlxsw_sp_inetaddr_bridge_event: Add an argument
For purposes of replay, mlxsw_sp_inetaddr_bridge_event() will need to make decisions based on the proposed value of PVID. Querying PVID reveals the current settings, not the in-flight values that the user requested and that the notifiers are acting upon. Add a parameter, lower_pvid, which carries the proposed PVID of the lower bridge, or -1 if the lower is not a bridge.
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 ...
|
#
a24a4d29 |
| 13-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Adjust mlxsw_sp_inetaddr_vlan_event() coding style
The bridge branch of the dispatch in this function is going to get more code and will need curly braces. Per the doctrine,
mlxsw: spectrum_router: Adjust mlxsw_sp_inetaddr_vlan_event() coding style
The bridge branch of the dispatch in this function is going to get more code and will need curly braces. Per the doctrine, that means the whole if-else chain should get them.
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 ...
|
#
a0944b24 |
| 13-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Take VID for VLAN FIDs from RIF params
Currently, when an IP address is added to a bridge that has no PVID, the operation is rejected. An IP address addition is interpreted a
mlxsw: spectrum_router: Take VID for VLAN FIDs from RIF params
Currently, when an IP address is added to a bridge that has no PVID, the operation is rejected. An IP address addition is interpreted as a request to create a RIF for the bridge device, but without a PVID there is no VLAN for which the RIF should be created. Thus the correct way to create a RIF for a bridge as a user is to first add a PVID, and then add the IP address.
Ideally this ordering requirement would not exist. RIF would be created either because an IP address is added, or because a PVID is added, depending on which comes last.
For that, the switchdev code (which notices the PVID change request) must be able to request that a RIF is created with a given VLAN ID, because at the time that the PVID notification is distributed, the PVID setting is not yet visible for querying.
Therefore when creating a VLAN-based RIF, use mlxsw_sp_rif_params.vid to communicate the VID, and do not determine it ad-hoc in the fid_get callback.
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 ...
|
#
5ca9f42c |
| 13-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Pass struct mlxsw_sp_rif_params to fid_get
The fid_get callback is called to allocate a FID for the newly-created RIF. In a following patch, the fid_get implementation for VL
mlxsw: spectrum_router: Pass struct mlxsw_sp_rif_params to fid_get
The fid_get callback is called to allocate a FID for the newly-created RIF. In a following patch, the fid_get implementation for VLANs will be modified to take the VLAN ID from the parameters instead of deducing it from the netdevice. To that end, propagate the RIF parameters to the fid_get callback.
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 ...
|
Revision tags: v6.1.38 |
|
#
90a8007b |
| 03-Jul-2023 |
Dan Carpenter <dan.carpenter@linaro.org> |
mlxsw: spectrum_router: Fix an IS_ERR() vs NULL check
The mlxsw_sp_crif_alloc() function returns NULL on error. It doesn't return error pointers. Fix the check.
Fixes: 78126cfd5dc9 ("mlxsw: spect
mlxsw: spectrum_router: Fix an IS_ERR() vs NULL check
The mlxsw_sp_crif_alloc() function returns NULL on error. It doesn't return error pointers. Fix the check.
Fixes: 78126cfd5dc9 ("mlxsw: spectrum_router: Maintain CRIF for fallback loopback RIF") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v6.1.37, v6.1.36, v6.4 |
|
#
9464a3d6 |
| 22-Jun-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Track next hops at CRIFs
Move the list of next hops from struct mlxsw_sp_rif to mlxsw_sp_crif. The reason is that eventually, next hops for mlxsw uppers should be offloaded a
mlxsw: spectrum_router: Track next hops at CRIFs
Move the list of next hops from struct mlxsw_sp_rif to mlxsw_sp_crif. The reason is that eventually, next hops for mlxsw uppers should be offloaded and unoffloaded on demand as a netdevice becomes an upper, or stops being one. Currently, next hops are tracked at RIFs, but RIFs do not exist when a netdevice is not an mlxsw uppers. CRIFs are kept track of throughout the netdevice lifetime.
Correspondingly, track at each next hop not its RIF, but its CRIF (from which a RIF can always be deduced).
Note that now that next hops are tracked at a CRIF, it is not necessary to move each over to a new RIF when it is necessary to edit a RIF. Therefore drop mlxsw_sp_nexthop_rif_migrate() and have mlxsw_sp_rif_migrate_destroy() call mlxsw_sp_nexthop_rif_update() directly.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Link: https://lore.kernel.org/r/e7c1c0a7dd13883b0f09aeda12c4fcf4d63a70e3.1687438411.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
a285d664 |
| 22-Jun-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Split nexthop finalization to two stages
Nexthop finalization consists of two steps: the part where the offload is removed, because the backing RIF is now gone; and the part
mlxsw: spectrum_router: Split nexthop finalization to two stages
Nexthop finalization consists of two steps: the part where the offload is removed, because the backing RIF is now gone; and the part where the association to the RIF is severed.
Extract from mlxsw_sp_nexthop_type_fini() a helper that covers the unoffloading part, mlxsw_sp_nexthop_type_rif_gone(), so that it can later be called independently.
Note that this swaps around the ordering of mlxsw_sp_nexthop_ipip_fini() vs. mlxsw_sp_nexthop_rif_fini(). The current ordering is more of a historical happenstance than a conscious decision. The two cleanups do not depend on each other, and this change should have no observable effects.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Link: https://lore.kernel.org/r/7134559534c5f5c4807c3a1569fae56f8887e763.1687438411.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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 ...
|