Thread (87 messages) 87 messages, 6 authors, 2023-08-10

Re: [PATCH vhost v11 05/10] virtio_ring: introduce virtqueue_dma_dev()

From: Jason Wang <jasowang@redhat.com>
Date: 2023-08-08 02:26:22
Also in: bpf, virtualization

On Mon, Aug 7, 2023 at 2:15 PM Xuan Zhuo [off-list ref] wrote:
On Wed, 2 Aug 2023 09:49:31 +0800, Xuan Zhuo [off-list ref] wrote:
quoted
On Tue, 1 Aug 2023 12:17:47 -0400, "Michael S. Tsirkin" [off-list ref] wrote:
quoted
On Fri, Jul 28, 2023 at 02:02:33PM +0800, Xuan Zhuo wrote:
quoted
On Tue, 25 Jul 2023 19:07:23 +0800, Xuan Zhuo [off-list ref] wrote:
quoted
On Tue, 25 Jul 2023 03:34:34 -0400, "Michael S. Tsirkin" [off-list ref] wrote:
quoted
On Tue, Jul 25, 2023 at 10:13:48AM +0800, Xuan Zhuo wrote:
quoted
On Mon, 24 Jul 2023 09:43:42 -0700, Christoph Hellwig [off-list ref] wrote:
quoted
On Thu, Jul 20, 2023 at 01:21:07PM -0400, Michael S. Tsirkin wrote:
quoted
Well I think we can add wrappers like virtio_dma_sync and so on.
There are NOP for non-dma so passing the dma device is harmless.
Yes, please.

I am not sure I got this fully.

Are you mean this:
https://lore.kernel.org/all/20230214072704.126660-8-xuanzhuo@linux.alibaba.com/ (local)
https://lore.kernel.org/all/20230214072704.126660-9-xuanzhuo@linux.alibaba.com/ (local)

Then the driver must do dma operation(map and sync) by these virtio_dma_* APIs.
No care the device is non-dma device or dma device.
yes
quoted
Then the AF_XDP must use these virtio_dma_* APIs for virtio device.
We'll worry about AF_XDP when the patch is posted.
YES.

We discussed it. They voted 'no'.

http://lore.kernel.org/all/20230424082856.15c1e593@kernel.org (local)

Hi guys, this topic is stuck again. How should I proceed with this work?

Let me briefly summarize:
1. The problem with adding virtio_dma_{map, sync} api is that, for AF_XDP and
the driver layer, we need to support these APIs. The current conclusion of
AF_XDP is no.

2. Set dma_set_mask_and_coherent, then we can use DMA API uniformly inside
driver. This idea seems to be inconsistent with the framework design of DMA. The
conclusion is no.

3. We noticed that if the virtio device supports VIRTIO_F_ACCESS_PLATFORM, it
uses DMA API. And this type of device is the future direction, so we only
support DMA premapped for this type of virtio device. The problem with this
solution is that virtqueue_dma_dev() only returns dev in some cases, because
VIRTIO_F_ACCESS_PLATFORM is supported in such cases.
Could you explain the issue a little bit more?

E.g if we limit AF_XDP to ACESS_PLATFROM only, why does
virtqueue_dma_dev() only return dev in some cases?

Thanks
Otherwise NULL is returned.
quoted
quoted
quoted
This option is currently NO.

So I'm wondering what should I do, from a DMA point of view, is there any
solution in case of using DMA API?

Thank you

I think it's ok at this point, Christoph just asked you
to add wrappers for map/unmap for use in virtio code.
Seems like a cosmetic change, shouldn't be hard.
Yes, that is not hard, I has this code.

But, you mean that the wrappers is just used for the virtio driver code?
And we also offer the  API virtqueue_dma_dev() at the same time?
Then the driver will has two chooses to do DMA.

Is that so?
Ping.

Thanks
quoted
quoted
Otherwise I haven't seen significant comments.


Christoph do I summarize what you are saying correctly?
--
MST
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help