[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <438c1e8f-b29f-4ab7-866a-fc5688e918f3@kernel.org>
Date: Tue, 7 May 2024 19:58:06 -0600
From: David Ahern <dsahern@...nel.org>
To: Mina Almasry <almasrymina@...gle.com>, Jakub Kicinski <kuba@...nel.org>
Cc: Jacob Keller <jacob.e.keller@...el.com>,
Alexander Lobakin <aleksander.lobakin@...el.com>,
Saeed Mahameed <saeedm@...dia.com>, Tariq Toukan <tariqt@...dia.com>,
Jason Gunthorpe <jgg@...dia.com>,
Andrew Gospodarek <andrew.gospodarek@...adcom.com>,
"michael.chan@...adcom.com" <michael.chan@...adcom.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Jiri Pirko <jiri@...dia.com>, Alexander Duyck <alexander.duyck@...il.com>,
Willem de Bruijn <willemb@...gle.com>,
Pavel Begunkov <asml.silence@...il.com>, David Wei <dw@...idwei.uk>,
Shailend Chand <shailend@...gle.com>
Subject: Re: Driver and H/W APIs Workshop at netdevconf
On 5/7/24 12:17 PM, Mina Almasry wrote:
> On Mon, May 6, 2024 at 6:06 PM Jakub Kicinski <kuba@...nel.org> wrote:
>>
>> On Mon, 6 May 2024 13:59:31 -0600 David Ahern wrote:
>>> Suggested topics based on recent netdev threads include
>>> - devlink - extensions, shortcomings, ...
>>> - extension to memory pools
>>> - new APIs for managing queues
>>> - challenges of netdev / IB co-existence (e.g., driven by AI workloads)
>>> - fwctl - a proposal for direct firmware access
>>
>> Memory pools and queue API are more of stack features.
>> Please leave them out of your fwctl session.
>>
>> Aren't people who are actually working on those things submitting
>> talks or hosting better scoped discussions? It appears you haven't
>> CCed any of them..
>>
>
> Me/Willem/Pavel/David/Shailend (I know, list is long xD), submitted a
> Devem TCP + Io_uring joint talk. We don't know if we'll get accepted.
> So far we plan to cover netmem + memory pools out of that list. We
> didn't plan to cover queue-API yet because we didn't have it accepted
> at talk submission time, but we just got it accepted so I was gonna
> reach out anyway to see if folks would be OK to have it in our talk.
>
> Any objection to having queue-API discussed as part of our talk? Or
> add some of us to yours? I'm fine with whatever. Just thought it fits
> well as part of this Devmem TCP + io_uring talk.
>
The queue API is a suggested topic given its newness. The current 4 ndos
and "ndo_queue_mem_size" were created based on gve. Are they sufficient
for other hardware vendors? Are extensions needed? Other use cases?
Discussions items if needed; maybe what exists is fine. Either way if
someone wanted to discuss, the scope for the workshop would be driver
APIs and down (driver code only).
Your use case is a driver capability upward.
To me a clear boundary.
Powered by blists - more mailing lists