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.
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).