Commit graph

5 commits

Author SHA1 Message Date
Beniamino Galvani
e8a3cd611e platform: move ethtool ioctl functions to a separate file
We're going to replace most of the ioctl-based ethtool functions with
a netlink-based equivalent. Move the ioctl ones to a separate file so
that it's easier to see what still needs to be converted. Also add a
common prefix to the function names.
2025-04-17 08:10:49 +02:00
Íñigo Huguet
3df94a4f2e sriov: allow reading empty eswitch paramaters via Devlink
Probably not all drivers and devices return all parameters. Set them to
"unknown" if they are missing and let the caller to decide what to do.

In our case, if the sriov setting has a value different to "preserve" it
will try to set it (and will probably fail). But if the missing
parameter is set to "preserve" in the sriov setting we can continue,
just ignoring it.

(cherry picked from commit 7346c5b556)
2024-02-21 11:27:36 +01:00
Íñigo Huguet
f0133e1a5e sriov: set the devlink's eswitch inline-mode and encap-mode
Set these parameters according to the values set in the new properties
sriov.eswitch-inline-mode and sriov.eswitch-encap-mode.

The number of parameters related to SR-IOV was becoming too big.
Refactor to group them in a NMPlatformSriovParams struct and pass it
around.

(cherry picked from commit 4669f01eb0)
2024-02-21 11:27:32 +01:00
Íñigo Huguet
03aaff8fc2 devlink: get and set eswitch inline-mode and encap-mode
The setter function allow to set to "preserve" to modify only some of
them.

(cherry picked from commit bf654ef39e)
2024-02-21 11:27:31 +01:00
Íñigo Huguet
61788cf901 platform: netlink: add devlink support
Add support for Devlink, which is just another family of Generic Netlink
like nl80211. Implement get_eswitch_mode and set_eswitch_mode to allow
changing between legacy SRIOV and switchdev modes.

Devlink's purpose is to allow querying and configuring stuff related to
a piece of hardware but not to any of the usual Linux device classes.

For example, nowadays the Smart NICs normally allow to change the
eswitch mode per PF, because their hardware implements one eswitch per
PF, but future models might have a single eswitch for all the physical
and virtual ports of the NIC allowing more advanced bridge offloads.

Regarding the above example, for the moment we only support PCI network
devices with the "one eswitch per PF" model. The reason is that currently
NM only knows about netdevs so dealing with "devlink devices" that
doesn't map 1-1 with a netdev would require new mechanisms to understand
what they are and their relation with the netdevs that NM manage. We
will deal with that use cases when they arise and we have more
information about the right way to support them.

(cherry picked from commit f31d29bbb7)
2024-02-21 11:27:28 +01:00