search for: xsk

Here, this has cc the maintainers of AF_XDP. For on the same page, I summarize it. We discusses this question last at [1]. We planned to pass one device to xsk. Then xsk can use the DMA API on this device. The device can be one hw device(such as PCI, mmio) or virtio device. If it is one hw device, no problem. If it is one virtio device, then we expect that DMA API on that will return direct dma map, because the dma_ops of the virtio device is NULL. But on...

On Thu, Apr 20, 2023 at 09:18:21AM -0700, Christoph Hellwig wrote: > On Thu, Apr 20, 2023 at 05:11:48PM +0800, Xuan Zhuo wrote: > > I know that the current design of DMA API only supports some physical hardware, > > but can it be modified or expanded? > > I think the important point is that for some cases there is no need > to dma map at all, and upper layers should be

On Thu, Apr 20, 2023 at 06:42:17PM +0200, Alexander Lobakin wrote: > When there's no recycling of pages, then yes. And since recycling is > done asynchronously, sometimes new allocations happen either way. > Anyways, that was roughly a couple years ago right when you introduced > dma_alloc_noncoherent(). Things might've been changed since then. > I could try again while next

On Wed, Apr 19, 2023 at 09:45:06AM -0700, Jakub Kicinski wrote: > > Can you explain what the actual use case is? > > > > From the original patchset I suspect it is dma mapping something very > > long term and then maybe doing syncs on it as needed? > > In this case yes, pinned user memory, it gets sliced up into MTU sized > chunks, fed into an Rx queue of a

...t virtio-net.c into multiple independent > > > > > module files. > > > > > > > > > > This is beneficial to the maintenance and adding new functions. > > > > > > > > > > And AF_XDP support will be added later, then a separate xsk.c file will > > > > > be added. > > > > > > > > > > This patchset split virtio-net.c into these parts: > > > > > > > > > > * virtnet.c: virtio net device ops (napi, tx, rx, device ops, ...) > > > > > *...

...ev, the caller should use DMA API. > > > > > > > > > > > > cc the XDP_SOCKET's maintainers. > > > > > > > > First of all, Jason does not want to encapsulate the API of DMA by Virtio. It is > > > > best to pass DMA Device to XSK, XSK uses DMA API for DMA MAP operation directly. > > > > I agree with this idea. > > > > > > > > However, there are several problems under Virtio: > > > > 1. In some virtualization scenarios, we do not have to perform DMA operations, > > > &...

...address directly. If > > > this func return a dma_dev, the caller should use DMA API. > > > > > > cc the XDP_SOCKET's maintainers. > > > > First of all, Jason does not want to encapsulate the API of DMA by Virtio. It is > > best to pass DMA Device to XSK, XSK uses DMA API for DMA MAP operation directly. > > I agree with this idea. > > > > However, there are several problems under Virtio: > > 1. In some virtualization scenarios, we do not have to perform DMA operations, > > just use the physical address directly. &gt...

...aller will use the physical memory address directly. If > > this func return a dma_dev, the caller should use DMA API. > > > cc the XDP_SOCKET's maintainers. > > First of all, Jason does not want to encapsulate the API of DMA by Virtio. It is > best to pass DMA Device to XSK, XSK uses DMA API for DMA MAP operation directly. > I agree with this idea. > > However, there are several problems under Virtio: > 1. In some virtualization scenarios, we do not have to perform DMA operations, > just use the physical address directly. This is not a problem, we c...

...o add, it is time to split virtio-net.c into multiple independent > > > > module files. > > > > > > > > This is beneficial to the maintenance and adding new functions. > > > > > > > > And AF_XDP support will be added later, then a separate xsk.c file will > > > > be added. > > > > > > > > This patchset split virtio-net.c into these parts: > > > > > > > > * virtnet.c: virtio net device ops (napi, tx, rx, device ops, ...) > > > > * virtnet_common.c: virtio net...

...; > If it returns NULL, the caller will use the physical memory address directly. If > this func return a dma_dev, the caller should use DMA API. cc the XDP_SOCKET's maintainers. First of all, Jason does not want to encapsulate the API of DMA by Virtio. It is best to pass DMA Device to XSK, XSK uses DMA API for DMA MAP operation directly. I agree with this idea. However, there are several problems under Virtio: 1. In some virtualization scenarios, we do not have to perform DMA operations, just use the physical address directly. 2. The latest Virtio Core supports each rx/tx queue...

## About DMA APIs Now, virtio may can not work with DMA APIs when virtio features do not have VIRTIO_F_ACCESS_PLATFORM. 1. I tried to let DMA APIs return phy address by virtio-device. But DMA APIs just work with the "real" devices. 2. I tried to let xsk support callballs to get phy address from virtio-net driver as the dma address. But the maintainers of xsk may want to use dma-buf to replace the DMA APIs. I think that may be a larger effort. We will wait too long. So rethinking this, firstly, we can support premapped-dma only for device...

...we want > > > to add, it is time to split virtio-net.c into multiple independent > > > module files. > > > > > > This is beneficial to the maintenance and adding new functions. > > > > > > And AF_XDP support will be added later, then a separate xsk.c file will > > > be added. > > > > > > This patchset split virtio-net.c into these parts: > > > > > > * virtnet.c: virtio net device ops (napi, tx, rx, device ops, ...) > > > * virtnet_common.c: virtio net common code > > > *...

## About DMA APIs Now, virtio may can not work with DMA APIs when virtio features do not have VIRTIO_F_ACCESS_PLATFORM. 1. I tried to let DMA APIs return phy address by virtio-device. But DMA APIs just work with the "real" devices. 2. I tried to let xsk support callballs to get phy address from virtio-net driver as the dma address. But the maintainers of xsk may want to use dma-buf to replace the DMA APIs. I think that may be a larger effort. We will wait too long. So rethinking this, firstly, we can support premapped-dma only for device...

## About DMA APIs Now, virtio may can not work with DMA APIs when virtio features do not have VIRTIO_F_ACCESS_PLATFORM. 1. I tried to let DMA APIs return phy address by virtio-device. But DMA APIs just work with the "real" devices. 2. I tried to let xsk support callballs to get phy address from virtio-net driver as the dma address. But the maintainers of xsk may want to use dma-buf to replace the DMA APIs. I think that may be a larger effort. We will wait too long. So rethinking this, firstly, we can support premapped-dma only for device...

On Mon, Feb 20, 2023 at 3:02 PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > On Mon, 20 Feb 2023 13:38:24 +0800, Jason Wang <jasowang at redhat.com> wrote: > > On Tue, Feb 14, 2023 at 3:27 PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > > > > > Added virtio_dma_map() to map DMA addresses for virtual memory in > > > advance.

On Mon, Feb 20, 2023 at 3:02 PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > On Mon, 20 Feb 2023 13:38:24 +0800, Jason Wang <jasowang at redhat.com> wrote: > > On Tue, Feb 14, 2023 at 3:27 PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > > > > > Added virtio_dma_map() to map DMA addresses for virtual memory in > > > advance.

## About DMA APIs Now, virtio may can not work with DMA APIs when virtio features do not have VIRTIO_F_ACCESS_PLATFORM. 1. I tried to let DMA APIs return phy address by virtio-device. But DMA APIs just work with the "real" devices. 2. I tried to let xsk support callballs to get phy address from virtio-net driver as the dma address. But the maintainers of xsk may want to use dma-buf to replace the DMA APIs. I think that may be a larger effort. We will wait too long. So rethinking this, firstly, we can support premapped-dma only for device...

...dering the complexity of virtio-net.c and the new features we want > to add, it is time to split virtio-net.c into multiple independent > module files. > > This is beneficial to the maintenance and adding new functions. > > And AF_XDP support will be added later, then a separate xsk.c file will > be added. > > This patchset split virtio-net.c into these parts: > > * virtnet.c: virtio net device ops (napi, tx, rx, device ops, ...) > * virtnet_common.c: virtio net common code > * virtnet_ethtool.c: virtio net ethtool callbacks > * virtnet_ctrl....

XDP socket(AF_XDP) is an excellent bypass kernel network framework. The zero copy feature of xsk (XDP socket) needs to be supported by the driver. The performance of zero copy is very good. ENV: Qemu with vhost. vhost cpu | Guest APP CPU |Guest Softirq CPU | PPS -----------------------------|---------------|------------------|------------ xmit by sockperf: 90% | 1...

## About DMA APIs Now, virtio may can not work with DMA APIs when virtio features do not have VIRTIO_F_ACCESS_PLATFORM. 1. I tried to let DMA APIs return phy address by virtio-device. But DMA APIs just work with the "real" devices. 2. I tried to let xsk support callballs to get phy address from virtio-net driver as the dma address. But the maintainers of xsk may want to use dma-buf to replace the DMA APIs. I think that may be a larger effort. We will wait too long. So rethinking this, firstly, we can support premapped-dma only for device...