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: <857e7a19-1559-b929-fd15-05e8f38e9d45@huawei.com>
Date:   Thu, 3 Jun 2021 11:46:43 +0800
From:   Yunsheng Lin <linyunsheng@...wei.com>
To:     Jakub Kicinski <kuba@...nel.org>
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 2021/6/3 0:34, Jakub Kicinski wrote:
> On Wed, 2 Jun 2021 10:24:11 +0800 Yunsheng Lin wrote:
>> On 2021/6/2 5:34, Jakub Kicinski wrote:
>>> On Tue, 1 Jun 2021 15:33:09 +0800 Yunsheng Lin wrote:  
>>>> Is there a reason why it didn't have to be solved yet?
>>>> Is it because the devices currently supporting devlink do not have
>>>> this kind of problem, like single-function ASIC or multi-function
>>>> ASIC without sharing common resource?  
>>>
>>> I'm not 100% sure, my guess is multi-function devices supporting
>>> devlink are simple enough for the problem not to matter all that much.
>>>   
>>>> Was there a discussion how to solved it in the past?  
>>>
>>> Not really, we floated an idea of creating aliases for devlink
>>> instances so a single devlink instance could answer to multiple 
>>> bus identifiers. But nothing concrete.  
>>
>> What does it mean by "answer to multiple bus identifiers"? I
>> suppose it means user provides the bus identifiers when setting or
>> getting something, and devlink instance uses that bus identifiers
>> to differentiate different PF in the same ASIC?
> 
> Correct.
> 
>> 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

> 
>>>> "same control domain" means if it is controlled by a single host, not
>>>> by multi hosts, right?
>>>>
>>>> If the PF is not passed through to a vm using VFIO and other PF is still
>>>> in the host, then I think we can say it is controlled by a single host.
>>>>
>>>> And each PF is trusted with each other right now, at least at the driver
>>>> level, but not between VF.  
>>>
>>> Right, the challenge AFAIU is how to match up multiple functions into 
>>> a single devlink instance, when driver has to probe them one by one.  
>>
>> 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.