netdev - Re: [RFC PATCH v3 net-next] Documentation: devlink: Add devlink-sd

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: <2444399e-f25f-4157-b5d0-447450a95ef9@nvidia.com>
Date: Wed, 31 Jan 2024 13:37:33 -0800
From: William Tu <witu@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: bodong@...dia.com, jiri@...dia.com, netdev@...r.kernel.org,
 saeedm@...dia.com, "jacob.e.keller@...el.com" <jacob.e.keller@...el.com>,
 "aleksander.lobakin@...el.com" <aleksander.lobakin@...el.com>
Subject: Re: [RFC PATCH v3 net-next] Documentation: devlink: Add devlink-sd


On 1/31/24 12:45 PM, Jakub Kicinski wrote:
> External email: Use caution opening links or attachments
>
>
> On Wed, 31 Jan 2024 11:16:58 -0800 William Tu wrote:
>> On 1/31/24 11:06 AM, Jakub Kicinski wrote:
>>>> Thanks for taking a look. Yes, for our use case we only need this API.
>>> I'm not sure how to interpret that, I think you answered a different
>>> question :) To avoid any misunderstandings here - let me rephrase a
>>> bit: are you only going to use this API to configure representors?
>>> Is any other netdev functionality going to use shared pools (i.e. other
>>> than RDMA)?
>> oh, now I understand your question.
>>
>> Yes, this API is only to configure representors in switchdev mode.
>>
>> No other netdev functionality will use this API.
> Hm, interesting. I was asking because I recently heard some academic
> talk where the guy mentioned something along the lines of new nVidia
> NICs having this amazing feature of reusing free buffer pools while
> keeping completions separate. So I was worried this will scope creep
> from something we don't care about all that much (fallback traffic)
> to something we care about very much (e.g. container interfaces).
> Since you promise this is for representors only, it's a simpler
> conversation!

For the academic talk, is it this one?

https://www.usenix.org/conference/osdi23/presentation/pismenny

>
> Still, I feel like shared buffer pools / shared queues is how majority
> of drivers implement representors. Did you had a look around?

Yes, I look at Intel ICE driver, which also has representors. (Add to CC)

IIUC, it's still dedicated buffer for each reps, so this new API might help.

William