[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACGkMEsnto9APpDo1uzVJAWBwk9f8pt6D=J41tdf1ZQ63ADK9Q@mail.gmail.com>
Date: Fri, 26 May 2023 14:57:26 +0800
From: Jason Wang <jasowang@...hat.com>
To: Liang Chen <liangchen.linux@...il.com>
Cc: mst@...hat.com, virtualization@...ts.linux-foundation.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
xuanzhuo@...ux.alibaba.com, kuba@...nel.org, edumazet@...gle.com,
davem@...emloft.net, pabeni@...hat.com, alexander.duyck@...il.com
Subject: Re: [PATCH net-next 4/5] virtio_ring: Introduce DMA pre-handler
On Fri, May 26, 2023 at 1:47 PM Liang Chen <liangchen.linux@...il.com> wrote:
>
> Currently, DMA operations of virtio devices' data buffer are encapsulated
> within the underlying virtqueue implementation. DMA map/unmap operations
> are performed for each data buffer attached to/detached from the virtqueue,
> which is transparent and invisible to the higher-level virtio device
> drivers. This encapsulation makes it not viable for device drivers to
> introduce certain mechanisms, such as page pool, that require explicit
> management of DMA map/unmap. Therefore, by inserting a pre-handler before
> the generic DMA map/unmap operations, virtio device drivers have the
> opportunity to participate in DMA operations.
>
> Signed-off-by: Liang Chen <liangchen.linux@...il.com>
So Xuan is doing AF_XDP for the virtio-net that allows the DMA to be
mapped at least by the virtio-net.
It looks like a way to allow virtio-net to map and unmap the DMA
buffer by itself, but this patch goes into another way which seems to
query the address from the virtio core.
Personally, I think map and sync by the virtio-net driver seems clean.
But we can see.
Thanks
Powered by blists - more mailing lists