Merge tag 'mlx5-updates-2021-03-16' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5-updates-2021-03-16
mlx5 uplink representor netdev persistence.
Before this patchset we used to have separate netdevs for Native NIC mode
and Switchdev mode (uplink representor netdev), meaning that if user
switches modes between Native to Switchdev and vice versa, the driver
would cleanup the current netdev representor and create a new one for the
new mode, such behavior created an administrative nightmare for users,
where users need to be aware of such loss of both data path and control
path configurations, e.g. netdev attributes and arp/route tables,
where the later is more painful.
A simple solution for this is not to replace the netdev in first place
and use a single netdev to serve the uplink/physical port whether it is
in switchdev mode or native mode.
We already have different HW profiles for each netdev mode, in this series
we just replace the HW profile on the fly and we keep the same netdev
attached.
Refactoring: Some refactoring has been made to overcome some technical
difficulties
1) The netdev is created with the maximum amount of tx/rx queues to serve
the two profiles.
2) Some ndos are not supported in some modes, so we added a mode check for
such cases, e.g legacy sriov ndos must be blocked in switchdev mode.
3) Some mlx5 netdev private attributes need to be moved out of profiles
and kept in a persistent place, where the netdev is created
e.g devlink port and other global HW resources
4) The netdev devlink port is now always registered with the switch id
Implementation: the last three patches implement the mechanism now as the
netdev can be shared.
5) Don't recreate the netdev on switchdev mode changes
6) Prevent changing switchdev mode when some netdev operations
are active, mostly when TC rules are being processed.
This is required since the netdev is kept registered while switchdev mode
can be changed.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Showing
Please register or sign in to comment