Messages in this thread | | | Date | Thu, 3 Jun 2021 10:53:11 -0700 | From | Jakub Kicinski <> | Subject | Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension |
| |
On Thu, 3 Jun 2021 11:46:43 +0800 Yunsheng Lin wrote: > >> can devlink port be used to indicate different PF in the same ASIC, > >> which already has the bus identifiers in it? It seems we need a > >> extra identifier to indicate the ASIC? > >> > >> $ devlink port show > >> ... > >> pci/0000:03:00.0/61: type eth netdev sw1p1s0 split_group 0 > > > > Ports can obviously be used, but which PCI device will you use to > > register the devlink instance? Perhaps using just one doesn't matter > > if there is only one NIC in the system, but may be confusing with > > multiple NICs, no? > > Yes, it is confusing, how about using the controler_id to indicate > different NIC? we can make sure controler_id is unqiue in the same > host, a controler_id corresponds to a devlink instance, vendor info > or serial num for the devlink instance can further indicate more info > to the system user? > > pci/controler_id/0000:03:00.0/61
What is a "controller id" in concrete terms? Another abstract ID which may change on every boot?
> >> Does it make sense if the PF first probed creates a auxiliary device, > >> and the auxiliary device driver creates the devlink instance? And > >> the PF probed later can connect/register to that devlink instance? > > > > I would say no, that just adds another layer of complication and > > doesn't link the functions in any way. > > How about: > The PF first probed creates the devlink instance? PF probed later can > connect/register to that devlink instance created by the PF first probed. > It seems some locking need to ensure the above happens as intended too. > > About linking, the PF provide vendor info/serial number(or whatever is > unqiue between different vendor) of a controller it belong to, if the > controller does not exist yet, create one and connect/register to that > devlink instance, otherwise just do the connecting/registering.
Sounds about right, but I don't understand why another ID is necessary. Why not allow devlink instances to have multiple names, like we allow aliases for netdevs these days?
| |