On 2021/6/9 1:29, Jakub Kicinski wrote:
On Tue, 8 Jun 2021 20:10:37 +0800 Yunsheng Lin wrote:
I am not sure if controller concept already existed is reusable for the devlink instance representing problem for multi-function which shares common resource in the same ASIC. If not, we do need to pick up other name.
Another thing I am not really think throught is how is the VF represented by the devlink instance when VF is passed through to a VM. I was thinking about VF is represented as devlink port, just like PF(with different port flavour), and VF devlink port only exist on the same host as PF(which assumes PF is never passed through to a VM), so it may means the PF is responsible for creating the devlink port for VF when VF is passed through to a VM?
Or do we need to create a devlink instance for VF in the VM too when the VF is passed through to a VM? Or more specificly, does user need to query or configure devlink info or configuration in a VM? If not, then devlink instance in VM seems unnecessary?
I believe the current best practice is to create a devlink instance for the VF with a devlink port of type "virtual". Such instance represents a "virtualized" view of the device.
Afer discussion with Parav in other thread, I undersood it was the current practice, but I am not sure I understand why it is current *best* practice.
If we allow all PF of a ASCI to register to the same devlink instance, does it not make sense that all VF under one PF also register to the same devlink instance that it's PF is registering to when they are in the same host?
For eswitch legacy mode, whether VF and PF are the same host or not, the VF can also provide the serial number of a ASIC to register to the devlink instance, if that devlink instance does not exist yet, just create that devlink instance according to the serial number, just like PF does.
For eswitch DEVLINK_ESWITCH_MODE_SWITCHDEV mode, the flavour type for devlink port instance representing the netdev of VF function is FLAVOUR_VIRTUAL, the flavour type for devlink port instance representing the representor netdev of VF is FLAVOUR_PCI_VF, which are different type, so they can register to the same devlink instance even when both of the devlink port instance is in the same host?
Is there any reason why VF use its own devlink instance?
Primary use case for VFs is virtual environments where guest isn't trusted, so tying the VF to the main devlink instance, over which guest should have no control is counter productive.
The security is mainly about VF using in container case, right? Because VF using in VM, it is different host, it means a different devlink instance for VF, so there is no security issue for VF using in VM case? But it might not be the case for VF using in container?
Also I read about the devlink disscusion betwwen you and jiri in [1]: "I think we agree that all objects of an ASIC should be under one devlink instance, the question remains whether both ends of the pipe for PCI devices (subdevs or not) should appear under ports or does the "far end" (from ASICs perspective)/"host end" get its own category."
I am not sure if there is already any conclusion about the latter part (I did not find the conclusion in that thread)?
"far end" (from ASICs perspective)/"host end" means PF/VF, right? Which seems to correspond to port flavor of FLAVOUR_PHYSICAL and FLAVOUR_VIRTUAL if we try to represent PF/VF using devlink port instance?
It seems the conclusion is very important to our disscusion in this thread, as we are trying to represent PF/VF as devlink port instance in this thread(at least that is what I think, hns3 does not support eswitch SWITCHDEV mode yet).
Also, there is a "switch_id" concept from jiri's example, which seems to be not implemented yet? pci/0000:05:00.0/10000: type eth netdev enp5s0npf0s0 flavour pci_pf pf 0 subport 0 switch_id 00154d130d2f
1. https://lore.kernel.org/netdev/20190304164007.7cef8af9@cakuba.netronome.com/...
I meant we could still allow the user to provide a more meaningful name to indicate a devlink instance besides the id.
To clarify/summarize my statement above serial number may be a useful addition but PCI device names should IMHO remain the primary identifiers, even if it means devlink instances with multiple names.
I am not sure I understand what does it mean by "devlink instances with multiple names"?
Does that mean whenever a devlink port instance is registered to a devlink instance, that devlink instance get a new name according to the PCI device which the just registered devlink port instance corresponds to?
Not devlink port, new PCI device. Multiple ports may reside on the same PCI function, some ports don't have a function (e.g. Ethernet ports).
Multiple ports on the same mainly PCI function means subfunction from mlx, right?
“some ports don't have a function (e.g. Ethernet ports)” does not seem exist yet? For now devlink port instance of FLAVOUR_PHYSICAL represents both PF and Ethernet ports?
.