Re: [PATCH net-next v18 07/14] memory-provider: dmabuf devmem memory provider

From
Jakub Kicinski <kuba@kernel.org>
Date
2024-08-12 23:57:11
Also in
bpf, dri-devel, linux-alpha, linux-arch, linux-doc, linux-kselftest, linux-media, linux-mips, lkml, netdev, sparclinux
Reply to
Pavel Begunkov, 2024-08-12
On Mon, 12 Aug 2024 20:10:39 +0100 Pavel Begunkov wrote:
quoted
1. Drivers need to be able to say "I support unreadable netmem".
Failure to report unreadable netmem support should cause the netlink
API to fail when the user tries to bind dmabuf/io uring memory.

2. Drivers need to be able to say "I want a header pool (with readable
netmem)" or "I want a data pool (potentially with unreadable netmem)".

Pavel is suggesting implementing both of these in 2 different flags.

Jakub is suggesting implementing both with 1 flag which says "I can
support unreadable netmem for this pool" , and guarding against #1
with a refcount check to detect if a dmabuf pool should have been
created but wasn't.  
That would be iffy IIUC, but I think Jakub just explicitly said
that the refcount trick was just for debugging purposes and not
for gauging errors like "providers are not supported by the driver".

"Yup, the refcount (now: check of the page pool list) was meant
as a WARN_ONCE() to catch bad drivers."
Sorry, insufficient caffeine level in the morning.
We can't WARN_ONCE(), indeed.
Thread (41 messages) 41 messages, 3 authors, last reply 2024-08-13
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help