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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210604114109.3a7ada85@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Fri, 4 Jun 2021 11:41:09 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Yunsheng Lin <linyunsheng@...wei.com>
Cc:     moyufeng <moyufeng@...wei.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Parav Pandit <parav@...lanox.com>,
        Or Gerlitz <gerlitz.or@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "michal.lkml@...kovi.net" <michal.lkml@...kovi.net>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Jiri Pirko <jiri@...lanox.com>,
        Salil Mehta <salil.mehta@...wei.com>,
        "lipeng (Y)" <lipeng321@...wei.com>,
        Guangbin Huang <huangguangbin2@...wei.com>,
        <shenjian15@...wei.com>, "chenhao (DY)" <chenhao288@...ilicon.com>,
        Jiaran Zhang <zhangjiaran@...wei.com>
Subject: Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension

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.