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

[Jakub Kicinski]

On Fri, 4 Jun 2021 09:18:04 +0800 Yunsheng Lin wrote:
> >> 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?  
> 
> 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.

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

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