Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, 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 |
|
#
7a3ce807 |
| 09-Aug-2023 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, fix peer entry ageing in LAG mode
With current implementation in single FDB LAG mode all packets are processed by eswitch 0 rules. As such, 'peer' FDB entries receive the packets f
net/mlx5: Bridge, fix peer entry ageing in LAG mode
With current implementation in single FDB LAG mode all packets are processed by eswitch 0 rules. As such, 'peer' FDB entries receive the packets for rules of other eswitches and are responsible for updating the main entry by sending SWITCHDEV_FDB_ADD_TO_BRIDGE notification from their background update wq task. However, this introduces a race condition when non-zero eswitch instance decides to delete a FDB entry, sends SWITCHDEV_FDB_DEL_TO_BRIDGE notification, but another eswitch's update task refreshes the same entry concurrently while its async delete work is still pending on the workque. In such case another SWITCHDEV_FDB_ADD_TO_BRIDGE event may be generated and entry will remain stuck in FDB marked as 'offloaded' since no more SWITCHDEV_FDB_DEL_TO_BRIDGE notifications are sent for deleting the peer entries.
Fix the issue by synchronously marking deleted entries with MLX5_ESW_BRIDGE_FLAG_DELETED flag and skipping them in background update job.
Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
b56fb19c |
| 11-Jul-2023 |
Roi Dayan <roid@nvidia.com> |
net/mlx5: Bridge, Only handle registered netdev bridge events
Don't handle bridge events for a netdev that doesn't belong to an eswitch that registered for bridge events.
Signed-off-by: Roi Dayan <
net/mlx5: Bridge, Only handle registered netdev bridge events
Don't handle bridge events for a netdev that doesn't belong to an eswitch that registered for bridge events.
Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Vlad Buslov <vladbu@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31 |
|
#
ade19f0d |
| 26-May-2023 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, pass net device when linking vport to bridge
Following patch requires access to additional data in bridge net_device. Pass the whole structure down the stack instead of adding nece
net/mlx5: Bridge, pass net device when linking vport to bridge
Following patch requires access to additional data in bridge net_device. Pass the whole structure down the stack instead of adding necessary fields as function arguments one-by-one.
Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2 |
|
#
55f3e740 |
| 14-Feb-2023 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, add tracepoints for multicast
Pass target struct net_device to mdb attach/detach handler in order to expose the port name to the new tracepoints. Implemented following tracepoints:
net/mlx5: Bridge, add tracepoints for multicast
Pass target struct net_device to mdb attach/detach handler in order to expose the port name to the new tracepoints. Implemented following tracepoints:
- Attach mdb to port. - Detach mdb from port.
Usage example:
># cd /sys/kernel/debug/tracing ># echo mlx5:mlx5_esw_bridge_port_mdb_attach >> set_event ># cat trace ... kworker/0:0-19071 [000] ..... 259004.253848: mlx5_esw_bridge_port_mdb_attach: net_device=enp8s0f0_0 addr=33:33:ff:00:00:01 vid=0 num_ports=1 offloaded=1
Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v6.1.12, v6.1.11, v6.1.10 |
|
#
70f0302b |
| 04-Feb-2023 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, implement mdb offload
Implement support for add/del SWITCHDEV_OBJ_ID_PORT_MDB events. For mdb destination addresses configure egress table rules to replicate to per-port multicast
net/mlx5: Bridge, implement mdb offload
Implement support for add/del SWITCHDEV_OBJ_ID_PORT_MDB events. For mdb destination addresses configure egress table rules to replicate to per-port multicast tables of all ports that are member of the multicast group as illustrated by 'MDB1' rule in the following diagram:
+--------+--+ +---------------------------------------> Port 1 | | | +-^------+--+ | | | | +-----------------------------------------+ | +---------------------------+ | | EGRESS table | | +--> PORT 1 multicast table | | +----------------------------------+ +-----------------------------------------+ | | +---------------------------+ | | INGRESS table | | | | | | | | +----------------------------------+ | dst_mac=P1,vlan=X -> pop vlan, goto P1 +--+ | | FG0: | | | | | dst_mac=P1,vlan=Y -> pop vlan, goto P1 | | | src_port=dst_port -> drop | | | src_mac=M1,vlan=X -> goto egress +---> dst_mac=P2,vlan=X -> pop vlan, goto P2 +--+ | | FG1: | | | ... | | dst_mac=P2,vlan=Y -> goto P2 | | | | VLAN X -> pop, goto port | | | | | dst_mac=MDB1,vlan=Y -> goto mcast P1,P2 +-----+ | ... | | +----------------------------------+ | | | | | VLAN Y -> pop, goto port +-------+ +-----------------------------------------+ | | | FG3: | | | | matchall -> goto port | | | | | | | +---------------------------+ | | | | | | +--------+--+ +---------------------------------------> Port 2 | | | +-^------+--+ | | | | | +---------------------------+ | +--> PORT 2 multicast table | | +---------------------------+ | | | | | FG0: | | | src_port=dst_port -> drop | | | FG1: | | | VLAN X -> pop, goto port | | | ... | | | | | | FG3: | | | matchall -> goto port +-------+ | | +---------------------------+
MDB is managed by extending mlx5 bridge to store an entry in mlx5_esw_bridge->mdb_list linked list (used to iterate over all offloaded MDBs) and mlx5_esw_bridge->mdb_ht hash table (used to lookup existing MDB by MAC+VLAN). Every MDB entry can be attached to arbitrary amount of bridge ports that are stored in mlx5_esw_bridge_mdb_entry->ports xarray in order to allow both efficient lookup of the port and also iteration over all ports that the entry is attached to. Every time MDB is attached/detached to/from a port, the hardware rule is recreated with list of destinations corresponding to all attached ports. When the entry is detached from the last port it is removed from mdb and destroyed which means that the ports xarray also acts as implicit reference counting mechanism.
Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
18c2916c |
| 21-Feb-2023 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, snoop igmp/mld packets
Handle SWITCHDEV_ATTR_ID_BRIDGE_MC_DISABLED attribute notification to dynamically toggle bridge multicast offload. Set new MLX5_ESW_BRIDGE_MCAST_FLAG bridge
net/mlx5: Bridge, snoop igmp/mld packets
Handle SWITCHDEV_ATTR_ID_BRIDGE_MC_DISABLED attribute notification to dynamically toggle bridge multicast offload. Set new MLX5_ESW_BRIDGE_MCAST_FLAG bridge flag when multicast offload is enabled. Put multicast-specific code into new bridge_mcast.c file.
When initializing bridge multicast pipeline create a static rule for snooping on IGMP traffic and three rules for snooping on MLD traffic (for query, report and done message types). Note that matching MLD traffic requires having flexparser MLX5_FLEX_PROTO_ICMPV6 capability enabled.
By default Linux bridge is created with multicast enabled which can be modified by 'mcast_snooping' argument:
$ ip link set name my_bridge type bridge mcast_snooping 0
Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v6.1.9 |
|
#
da0c5242 |
| 26-Jan-2023 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, fix ageing of peer FDB entries
SWITCHDEV_FDB_ADD_TO_BRIDGE event handler that updates FDB entry 'lastuse' field is only executed for eswitch that owns the entry. However, if peer e
net/mlx5: Bridge, fix ageing of peer FDB entries
SWITCHDEV_FDB_ADD_TO_BRIDGE event handler that updates FDB entry 'lastuse' field is only executed for eswitch that owns the entry. However, if peer entry processed packets at least once it will have hardware counter 'used' value greater than entry 'lastuse' from that point on, which will cause FDB entry not being aged out.
Process the event on all eswitch instances.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77 |
|
#
15f8f168 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower de
net/mlx5: Bridge, verify LAG state when adding bond to bridge
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45 |
|
#
c5fcac93 |
| 03-Jun-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, implement infrastructure for VLAN protocol change
Current implementation only supports 802.1Q VLAN Ethernet protocol. That protocol type is assumed by default and SWITCHDEV_ATTR_ID
net/mlx5: Bridge, implement infrastructure for VLAN protocol change
Current implementation only supports 802.1Q VLAN Ethernet protocol. That protocol type is assumed by default and SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL notification is ignored. To prepare for supporting 802.1ad protocol in following patches implement the necessary infrastructure to allow the user to dynamically change the VLAN protocol:
- Handle SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL notification by flushing FDB and re-creating VLAN modify header actions with new protocol. In this patch the only allowed dynamic VLAN protocol value is ETH_P_8021Q.
- Save current VLAN protocol in per-bridge instance variable. Use the dynamic variable instead of hardcoded values in mlx5 bridge code. Create VLAN flow groups and flows based on current mlx5_esw_bridge->vlan_proto value instead of assuming 802.1Q ethertype.
- Extract common flow group creation code into dedicated functions in order to be reused for creating QinQ groups in following patches.
Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17 |
|
#
880b5176 |
| 24-Jan-2022 |
Roi Dayan <roid@nvidia.com> |
net/mlx5: Bridge, Fix devlink deadlock on net namespace deletion
When changing mode to switchdev, rep bridge init registered to netdevice notifier holds the devlink lock and then takes pernet_ops_rw
net/mlx5: Bridge, Fix devlink deadlock on net namespace deletion
When changing mode to switchdev, rep bridge init registered to netdevice notifier holds the devlink lock and then takes pernet_ops_rwsem. At that time deleting a netns holds pernet_ops_rwsem and then takes the devlink lock.
Example sequence is: $ ip netns add foo $ devlink dev eswitch set pci/0000:00:08.0 mode switchdev & $ ip netns del foo
deleting netns trace:
[ 1185.365555] ? devlink_pernet_pre_exit+0x74/0x1c0 [ 1185.368331] ? mutex_lock_io_nested+0x13f0/0x13f0 [ 1185.370984] ? xt_find_table+0x40/0x100 [ 1185.373244] ? __mutex_lock+0x24a/0x15a0 [ 1185.375494] ? net_generic+0xa0/0x1c0 [ 1185.376844] ? wait_for_completion_io+0x280/0x280 [ 1185.377767] ? devlink_pernet_pre_exit+0x74/0x1c0 [ 1185.378686] devlink_pernet_pre_exit+0x74/0x1c0 [ 1185.379579] ? devlink_nl_cmd_get_dumpit+0x3a0/0x3a0 [ 1185.380557] ? xt_find_table+0xda/0x100 [ 1185.381367] cleanup_net+0x372/0x8e0
changing mode to switchdev trace:
[ 1185.411267] down_write+0x13a/0x150 [ 1185.412029] ? down_write_killable+0x180/0x180 [ 1185.413005] register_netdevice_notifier+0x1e/0x210 [ 1185.414000] mlx5e_rep_bridge_init+0x181/0x360 [mlx5_core] [ 1185.415243] mlx5e_uplink_rep_enable+0x269/0x480 [mlx5_core] [ 1185.416464] ? mlx5e_uplink_rep_disable+0x210/0x210 [mlx5_core] [ 1185.417749] mlx5e_attach_netdev+0x232/0x400 [mlx5_core] [ 1185.418906] mlx5e_netdev_attach_profile+0x15b/0x1e0 [mlx5_core] [ 1185.420172] mlx5e_netdev_change_profile+0x15a/0x1d0 [mlx5_core] [ 1185.421459] mlx5e_vport_rep_load+0x557/0x780 [mlx5_core] [ 1185.422624] ? mlx5e_stats_grp_vport_rep_num_stats+0x10/0x10 [mlx5_core] [ 1185.424006] mlx5_esw_offloads_rep_load+0xdb/0x190 [mlx5_core] [ 1185.425277] esw_offloads_enable+0xd74/0x14a0 [mlx5_core]
Fix this by registering rep bridges for per net netdev notifier instead of global one, which operats on the net namespace without holding the pernet_ops_rwsem.
Fixes: 19e9bfa044f3 ("net/mlx5: Bridge, add offload infrastructure") Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Vlad Buslov <vladbu@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
Revision tags: v5.4.173, v5.15.16, v5.15.15, v5.16 |
|
#
04f8c12f |
| 06-Jan-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, take rtnl lock in init error handler
The mlx5_esw_bridge_cleanup() is expected to be called with rtnl lock taken, which is true for mlx5e_rep_bridge_cleanup() function but not for
net/mlx5: Bridge, take rtnl lock in init error handler
The mlx5_esw_bridge_cleanup() is expected to be called with rtnl lock taken, which is true for mlx5e_rep_bridge_cleanup() function but not for error handling code in mlx5e_rep_bridge_init(). Add missing rtnl lock/unlock calls and extend both mlx5_esw_bridge_cleanup() and its dual function mlx5_esw_bridge_init() with ASSERT_RTNL() to verify the invariant from now on.
Fixes: 7cd6a54a8285 ("net/mlx5: Bridge, handle FDB events") Fixes: 19e9bfa044f3 ("net/mlx5: Bridge, add offload infrastructure") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
48b73b46 |
| 03-Nov-2022 |
Vlad Buslov <vladbu@nvidia.com> |
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for
net/mlx5: Bridge, verify LAG state when adding bond to bridge
[ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
Mlx5 LAG is initialized asynchronously on a workqueue which means that for a brief moment after setting mlx5 UL representors as lower devices of a bond netdevice the LAG itself is not fully initialized in the driver. When adding such bond device to a bridge mlx5 bridge code will not consider it as offload-capable, skip creating necessary bookkeeping and fail any further bridge offload-related commands with it (setting VLANs, offloading FDBs, etc.). In order to make the error explicit during bridge initialization stage implement the code that detects such condition during NETDEV_PRECHANGEUPPER event and returns an error.
Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|