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_noncoher
On Tue, Apr 25, 2023 at 04:12:05AM -0400, Michael S. Tsirkin wrote:
> In theory, absolutely. In practice modern virtio devices are ok,
> the reason we are stuck supporting old legacy ones is because legacy
> devices are needed to run old guests. And then people turn
> around and run a new guest 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 f
On Mon, 24 Apr 2023 17:28:01 +0200, Alexander Lobakin
wrote:
> From: Jakub Kicinski
> Date: Fri, 21 Apr 2023 06:50:59 -0700
>
> > On Fri, 21 Apr 2023 15:31:04 +0800 Xuan Zhuo wrote:
> >> I am not particularly familiar with dma-bufs. I want to know if this
> >> mechanism
> >> can solve the probl
On Fri, 21 Apr 2023 06:50:59 -0700, Jakub Kicinski wrote:
> On Fri, 21 Apr 2023 15:31:04 +0800 Xuan Zhuo wrote:
> > I am not particularly familiar with dma-bufs. I want to know if this
> > mechanism
> > can solve the problem of virtio-net.
> >
> > I saw this framework, allowing the driver do some
On Thu, 20 Apr 2023 07:13:49 -0700, Jakub Kicinski wrote:
> On Wed, 19 Apr 2023 23:19:22 -0700 Christoph Hellwig wrote:
> > > In this case yes, pinned user memory, it gets sliced up into MTU sized
> > > chunks, fed into an Rx queue of a device, and user can see packets
> > > without any copies.
>
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 fi
On Thu, Apr 20, 2023 at 03:59:39PM +0200, Alexander Lobakin wrote:
> Hmm, currently almost all Ethernet drivers map Rx pages once and then
> just recycle them, keeping the original DMA mapping. Which means pages
> can have the same first mapping for very long time, often even for the
> lifetime of
On Wed, 19 Apr 2023 23:19:22 -0700, Christoph Hellwig
wrote:
> 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
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 get
On Wed, Apr 19, 2023 at 03:14:48PM +0200, Alexander Lobakin wrote:
> >>> dma addresses and thus dma mappings are completely driver specific.
> >>> Upper layers have no business looking at them.
>
> Here it's not an "upper layer". XSk core doesn't look at them or pass
> them between several drivers
On Wed, Apr 19, 2023 at 03:22:39PM +0200, Alexander Lobakin wrote:
> If DMA syncs are not needed on your x86_64 DMA-coherent system, it
> doesn't mean we all don't need it.
If the DMA isn't actually a DMA (as in the virtio case, or other
cases that instead have to do their own dma mapping at much
On Wed, 19 Apr 2023 15:22:39 +0200, Alexander Lobakin
wrote:
> From: Xuan Zhuo
> Date: Mon, 17 Apr 2023 11:27:50 +0800
>
> > The purpose of this patch is to allow driver pass the own dma_ops to
> > xsk.
> >
> > This is to cope with the scene of virtio-net. If virtio does not have
> > VIRTIO_F_AC
On Wed, 19 Apr 2023 15:14:48 +0200, Alexander Lobakin
wrote:
> From: Christoph Hellwig
> Date: Tue, 18 Apr 2023 22:16:53 -0700
>
> > On Mon, Apr 17, 2023 at 11:19:47PM -0700, Jakub Kicinski wrote:
> >>> You can't just do dma mapping outside the driver, because there are
> >>> drivers that do not
On Mon, Apr 17, 2023 at 11:19:47PM -0700, Jakub Kicinski wrote:
> > You can't just do dma mapping outside the driver, because there are
> > drivers that do not require DMA mapping at all. virtio is an example,
> > but all the classic s390 drivers and some other odd virtualization
> > ones are othe
On Mon, Apr 17, 2023 at 07:54:00PM -0700, Jakub Kicinski wrote:
> AF_XDP, io_uring, and increasing number of pinned memory / zero copy
> implementations need to do DMA mapping outside the drivers.
You can't just do dma mapping outside the driver, because there are
drivers that do not require DMA m
On Mon, 17 Apr 2023 18:19:50 -0700, Jakub Kicinski wrote:
> On Tue, 18 Apr 2023 09:07:30 +0800 Jason Wang wrote:
> > > > Would you mind explaining this a bit more to folks like me who are not
> > > > familiar with VirtIO? DMA API is supposed to hide the DMA mapping
> > > > details from the stack,
On Mon, 17 Apr 2023 11:57:53 -0700, Jakub Kicinski wrote:
> On Mon, 17 Apr 2023 11:56:10 -0700 Jakub Kicinski wrote:
> > > May misunderstand, here the "dma_ops" is not the "dma_ops" of DMA API.
> > >
> > > I mean the callbacks for xsk to do dma.
> > >
> > > Maybe, I should rename it in the next ve
On Tue, Apr 18, 2023 at 2:58 AM Jakub Kicinski wrote:
>
> On Mon, 17 Apr 2023 11:56:10 -0700 Jakub Kicinski wrote:
> > > May misunderstand, here the "dma_ops" is not the "dma_ops" of DMA API.
> > >
> > > I mean the callbacks for xsk to do dma.
> > >
> > > Maybe, I should rename it in the next vers
On Mon, 17 Apr 2023 02:43:32 -0400, "Michael S. Tsirkin"
wrote:
> On Mon, Apr 17, 2023 at 11:27:50AM +0800, Xuan Zhuo wrote:
> > @@ -532,9 +545,9 @@ struct xdp_buff *xp_alloc(struct xsk_buff_pool *pool)
> > xskb->xdp.data_meta = xskb->xdp.data;
> >
> > if (pool->dma_need_sync) {
> > -
%40linux.alibaba.com
patch subject: [PATCH net-next] xsk: introduce xsk_dma_ops
config: mips-randconfig-r021-20230416
(https://download.01.org/0day-ci/archive/20230417/202304171441.ezrwcnsh-...@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project
On Mon, Apr 17, 2023 at 11:27:50AM +0800, Xuan Zhuo wrote:
> @@ -532,9 +545,9 @@ struct xdp_buff *xp_alloc(struct xsk_buff_pool *pool)
> xskb->xdp.data_meta = xskb->xdp.data;
>
> if (pool->dma_need_sync) {
> - dma_sync_single_range_for_device(pool->dev, xskb->dma, 0,
> -
%40linux.alibaba.com
patch subject: [PATCH net-next] xsk: introduce xsk_dma_ops
config: i386-randconfig-a011-20230417
(https://download.01.org/0day-ci/archive/20230417/202304171427.uaryn9jl-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project
On Sun, 16 Apr 2023 21:24:32 -0700, Christoph Hellwig
wrote:
> On Mon, Apr 17, 2023 at 11:27:50AM +0800, Xuan Zhuo wrote:
> > The purpose of this patch is to allow driver pass the own dma_ops to
> > xsk.
>
> Drivers have no business passing around dma_ops, or even knowing about
> them.
May misu
On Mon, Apr 17, 2023 at 11:27:50AM +0800, Xuan Zhuo wrote:
> The purpose of this patch is to allow driver pass the own dma_ops to
> xsk.
Drivers have no business passing around dma_ops, or even knowing about
them.
___
Virtualization mailing list
Virtuali
The purpose of this patch is to allow driver pass the own dma_ops to
xsk.
This is to cope with the scene of virtio-net. If virtio does not have
VIRTIO_F_ACCESS_PLATFORM, then virtio cannot use DMA API. In this case,
XSK cannot use DMA API directly to achieve DMA address. Based on this
scene, we mu
26 matches
Mail list logo
