Thread (41 messages) 41 messages, 3 authors, 2024-08-13

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

From: Jakub Kicinski <kuba@kernel.org>
Date: 2024-08-13 14:33:23
Also in: bpf, dri-devel, linux-alpha, linux-arch, linux-doc, linux-kselftest, linux-media, linux-mips, lkml, netdev, sparclinux

On Tue, 13 Aug 2024 04:39:47 -0400 Mina Almasry wrote:
On Mon, Aug 12, 2024 at 8:15 PM Jakub Kicinski [off-list ref] wrote:
quoted
BTW, Mina, the core should probably also check that XDP isn't installed
before / while the netmem is bound to a queue.  
Sorry if noob question, but what is the proper check for this?
	if (dev_xdp_prog_count(netdev))
I tried adding this to net_devmem_bind_dmabuf_to_queue():

if (xdp_rxq_info_is_reg(&rxq->xdp_rxq))
                 return -EEXIST;

But quickly found out that in  netif_alloc_rx_queues() we initialize
all the rxq->xdp_rxq to state REGISTERED regardless whether xdp is
installed or not, so this check actually fails.

Worthy of note is that GVE holds an instance of xdp_rxq_info in
gve_rx_ring, and seems to use that for its xdp information, not the
one that hangs off of netdev_rx_queue in core.

Additionally, my understanding of XDP is limited, but why do we want
to disable it? My understanding is that XDP is a kernel bypass that
hands the data directly to userspace. In theory at least there should
be no issue binding dmabuf to a queue, then getting the data in the
queue via an XDP program instead of via TCP sockets or io uring. Is
there some fundamental reason why dmabuf and XDP are incompatible?
You're conflating XDP with AF_XDP, two different things, slightly
related but different.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help