Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension

From: Jakub Kicinski
Date: Thu Jun 03 2021 - 13:54:04 EST


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?