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: <777fdb4a-f8f3-4ddb-896a-21b5048c07da@intel.com>
Date: Wed, 31 Jan 2024 13:41:07 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: William Tu <witu@...dia.com>, Jakub Kicinski <kuba@...nel.org>
CC: <bodong@...dia.com>, <jiri@...dia.com>, <netdev@...r.kernel.org>,
	<saeedm@...dia.com>, "aleksander.lobakin@...el.com"
	<aleksander.lobakin@...el.com>
Subject: Re: [RFC PATCH v3 net-next] Documentation: devlink: Add devlink-sd



On 1/31/2024 1:37 PM, William Tu wrote:
> 
> 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
> 

Yea, I am pretty sure the ice implementation uses dedicated buffers for
representors right now.