netdev - Re: [RFC PATCH net-next 08/19] pds_core: initial VF configuration

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: <fbf3266c-f125-c01a-fcc3-dc16b4055ed5@amd.com>
Date:   Tue, 29 Nov 2022 09:57:25 -0800
From:   Shannon Nelson <shnelson@....com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Shannon Nelson <snelson@...sando.io>, netdev@...r.kernel.org,
        davem@...emloft.net, mst@...hat.com, jasowang@...hat.com,
        virtualization@...ts.linux-foundation.org, drivers@...sando.io
Subject: Re: [RFC PATCH net-next 08/19] pds_core: initial VF configuration

On 11/28/22 5:54 PM, Jakub Kicinski wrote:
> On Mon, 28 Nov 2022 17:08:28 -0800 Shannon Nelson wrote:
>>> Don't even start with the "our device is simple and only needs
>>> the legacy API" line of arguing :/
>>
>> I'm not sure what else to say here - yes, we have a fancy and complex
>> piece of hardware plugged into the PCI slot, but the device that shows
>> up on the PCI bus is a very constrained model that doesn't know anything
>> about switchdev kinds of things.
> 
> Today it is, but I presume it's all FW underneath. So a year from now
> you'll be back asking for extensions because FW devs added features.

Sure, and that will be the time to add the APIs and code for handling 
the more complex switching and filtering needs.  We leave it out for now 
so as to not have unneeded code waiting for future features that might 
never actually appear, as driver writers are often reminded.

> 
>>>> The device model presented to the host is a simple PF with VFs, not a
>>>> SmartNIC, thus the pds_core driver sets up a simple PF netdev
>>>> "representor" for using the existing VF control API: easy to use,
>>>> everyone knows how to use it, keeps code simple.
>>>>
>>>> I suppose we could have the PF create a representor netdev for each
>>>> individual VF to set mac address and read stats, but that seems
>>>
>>> Oh, so the "representor" you mention in the cover letter is for the PF?
>>
>> Yes, a PF representor simply so we can get access to the .ndo_set_vf_xxx
>> interfaces.  There is no network traffic running through the PF.
> 
> In that case not only have you come up with your own name for
> a SmartNIC, you also managed to misuse one of our existing terms
> in your own way! It can't pass any traffic it's just a dummy to hook
> the legacy vf ndos to. It's the opposite of what a repr is.

Sorry, this seemed to me an reasonable use of the term.  Is there an 
alternative wording we should use for this case?

Are there other existing methods we can use for getting the VF 
configurations from the user, or does this make sense to keep in our 
current simple model?

Thanks,
sln