On 2021/6/8 3:46, Jakub Kicinski wrote:
On Mon, 7 Jun 2021 09:36:38 +0800 Yunsheng Lin wrote:
On 2021/6/5 2:41, Jakub Kicinski wrote:
On Fri, 4 Jun 2021 09:18:04 +0800 Yunsheng Lin wrote:
My initial thinking is a id from a global IDA pool, which indeed may change on every boot.
I am not really thinking much deeper about the controller id, just mirroring the bus identifiers for pcie device and ifindex for netdev,
devlink instance id seems fine, but there's already a controller concept in devlink so please steer clear of that naming.
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?
which may change too if the device is pluged into different pci slot on every boot?
Heh. What is someone reflashes the part to change it's serial number? :) pci slot is reasonably stable, as proven by years of experience trying to find stable naming for netdevs.
I suppose that requires a booting to take effect and a vendor tool to reflash the serial number, it seems reasonable the vendor/user will try their best to not mess the serial number, otherwise service and maintenance based on serial number will not work? I was thinking about adding the vendor name besides the serial number to indicate a devlink instance, to avoid that case that two hw from different vendor having the same serial number accidentally.
I'm not opposed to the use of attributes such as serial number for selecting instance, in principle. I was just trying to prove that PCI slot/PCI device name is as stable as any other attribute.
In fact for mass-produced machines using PCI slot is far more convenient than globally unique identifiers because it can be used to talk to a specific device in a server for all machines of a given model, hence easing automation.
Make sense.
We could still allow devlink instances to have multiple names, which seems to be more like devlink tool problem?
For example, devlink tool could use the id or the vendor_info/ serial_number to indicate a devlink instance according to user's request.
Typing serial numbers seems pretty painful.
Aliase could be allowed too as long as devlink core provide a field and ops to set/get the field mirroring the ifalias for netdevice?
I don't understand.
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?
In addition I don't think that user-controlled names/aliases are necessarily a great idea for devlink.
.