On 2021/6/9 1:29, Jakub Kicinski wrote:

On Tue, 8 Jun 2021 20:10:37 +0800 Yunsheng Lin wrote:

quoted

quoted

quoted

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/t/ (local)

quoted

quoted

quoted

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?

.