[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1709199386.9824007-2-xuanzhuo@linux.alibaba.com>
Date: Thu, 29 Feb 2024 17:36:26 +0800
From: Xuan Zhuo <xuanzhuo@...ux.alibaba.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: virtualization@...ts.linux.dev,
Richard Weinberger <richard@....at>,
Anton Ivanov <anton.ivanov@...bridgegreys.com>,
Johannes Berg <johannes@...solutions.net>,
Jason Wang <jasowang@...hat.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Hans de Goede <hdegoede@...hat.com>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
Vadim Pasternak <vadimp@...dia.com>,
Bjorn Andersson <andersson@...nel.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
Cornelia Huck <cohuck@...hat.com>,
Halil Pasic <pasic@...ux.ibm.com>,
Eric Farman <farman@...ux.ibm.com>,
Heiko Carstens <hca@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>,
Alexander Gordeev <agordeev@...ux.ibm.com>,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
Sven Schnelle <svens@...ux.ibm.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Jesper Dangaard Brouer <hawk@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
linux-um@...ts.infradead.org,
netdev@...r.kernel.org,
platform-driver-x86@...r.kernel.org,
linux-remoteproc@...r.kernel.org,
linux-s390@...r.kernel.org,
kvm@...r.kernel.org,
bpf@...r.kernel.org
Subject: Re: [PATCH vhost v3 00/19] virtio: drivers maintain dma info for premapped vq
On Thu, 29 Feb 2024 04:34:20 -0500, "Michael S. Tsirkin" <mst@...hat.com> wrote:
> On Thu, Feb 29, 2024 at 05:02:37PM +0800, Xuan Zhuo wrote:
> > On Thu, 29 Feb 2024 03:21:14 -0500, "Michael S. Tsirkin" <mst@...hat.com> wrote:
> > > On Thu, Feb 29, 2024 at 03:20:25PM +0800, Xuan Zhuo wrote:
> > > > As discussed:
> > > > http://lore.kernel.org/all/CACGkMEvq0No8QGC46U4mGsMtuD44fD_cfLcPaVmJ3rHYqRZxYg@mail.gmail.com
> > > >
> > > > If the virtio is premapped mode, the driver should manage the dma info by self.
> > > > So the virtio core should not store the dma info.
> > > > So we can release the memory used to store the dma info.
> > > >
> > > > But if the desc_extra has not dma info, we face a new question,
> > > > it is hard to get the dma info of the desc with indirect flag.
> > > > For split mode, that is easy from desc, but for the packed mode,
> > > > it is hard to get the dma info from the desc. And for hardening
> > > > the dma unmap is saft, we should store the dma info of indirect
> > > > descs.
> > > >
> > > > So I introduce the "structure the indirect desc table" to
> > > > allocate space to store dma info with the desc table.
> > > >
> > > > On the other side, we mix the descs with indirect flag
> > > > with other descs together to share the unmap api. That
> > > > is complex. I found if we we distinguish the descs with
> > > > VRING_DESC_F_INDIRECT before unmap, thing will be clearer.
> > > >
> > > > Because of the dma array is allocated in the find_vqs(),
> > > > so I introduce a new parameter to find_vqs().
> > > >
> > > > Note:
> > > > this is on the top of
> > > > [PATCH vhost v1] virtio: packed: fix unmap leak for indirect desc table
> > > > http://lore.kernel.org/all/20240223071833.26095-1-xuanzhuo@linux.alibaba.com
> > > >
> > > > Please review.
> > > >
> > > > Thanks
> > > >
> > > > v3:
> > > > 1. fix the conflict with the vp_modern_create_avq().
> > >
> > > Okay but are you going to address huge memory waste all this is causing for
> > > - people who never do zero copy
> > > - systems where dma unmap is a nop
> > >
> > > ?
> > >
> > > You should address all comments when you post a new version, not just
> > > what was expedient, or alternatively tag patch as RFC and explain
> > > in commit log that you plan to do it later.
> >
> >
> > Do you miss this one?
> > http://lore.kernel.org/all/1708997579.5613105-1-xuanzhuo@linux.alibaba.com
>
>
> I did. The answer is that no, you don't get to regress memory usage
> for lots of people then fix it up.
> So the patchset is big, I guess it will take a couple of cycles to
> merge gradually.
I see.
But I hope we can review the other part of this patch set. @Jason @Michael
I don't want us to give up on this plan for some other reason after I've done so
much work.
Thanks.
>
> > I asked you. But I didnot recv your answer.
> >
> > Thanks.
> >
> >
> > >
> > > > v2:
> > > > 1. change the dma item of virtio-net, every item have MAX_SKB_FRAGS + 2
> > > > addr + len pairs.
> > > > 2. introduce virtnet_sq_free_stats for __free_old_xmit
> > > >
> > > > v1:
> > > > 1. rename transport_vq_config to vq_transport_config
> > > > 2. virtio-net set dma meta number to (ring-size + 1)(MAX_SKB_FRGAS +2)
> > > > 3. introduce virtqueue_dma_map_sg_attrs
> > > > 4. separate vring_create_virtqueue to an independent commit
> > > >
> > > >
> > > >
> > > > Xuan Zhuo (19):
> > > > virtio_ring: introduce vring_need_unmap_buffer
> > > > virtio_ring: packed: remove double check of the unmap ops
> > > > virtio_ring: packed: structure the indirect desc table
> > > > virtio_ring: split: remove double check of the unmap ops
> > > > virtio_ring: split: structure the indirect desc table
> > > > virtio_ring: no store dma info when unmap is not needed
> > > > virtio: find_vqs: pass struct instead of multi parameters
> > > > virtio: vring_create_virtqueue: pass struct instead of multi
> > > > parameters
> > > > virtio: vring_new_virtqueue(): pass struct instead of multi parameters
> > > > virtio_ring: simplify the parameters of the funcs related to
> > > > vring_create/new_virtqueue()
> > > > virtio: find_vqs: add new parameter premapped
> > > > virtio_ring: export premapped to driver by struct virtqueue
> > > > virtio_net: set premapped mode by find_vqs()
> > > > virtio_ring: remove api of setting vq premapped
> > > > virtio_ring: introduce dma map api for page
> > > > virtio_ring: introduce virtqueue_dma_map_sg_attrs
> > > > virtio_net: unify the code for recycling the xmit ptr
> > > > virtio_net: rename free_old_xmit_skbs to free_old_xmit
> > > > virtio_net: sq support premapped mode
> > > >
> > > > arch/um/drivers/virtio_uml.c | 31 +-
> > > > drivers/net/virtio_net.c | 283 ++++++---
> > > > drivers/platform/mellanox/mlxbf-tmfifo.c | 24 +-
> > > > drivers/remoteproc/remoteproc_virtio.c | 31 +-
> > > > drivers/s390/virtio/virtio_ccw.c | 33 +-
> > > > drivers/virtio/virtio_mmio.c | 30 +-
> > > > drivers/virtio/virtio_pci_common.c | 59 +-
> > > > drivers/virtio/virtio_pci_common.h | 9 +-
> > > > drivers/virtio/virtio_pci_legacy.c | 16 +-
> > > > drivers/virtio/virtio_pci_modern.c | 38 +-
> > > > drivers/virtio/virtio_ring.c | 698 ++++++++++++-----------
> > > > drivers/virtio/virtio_vdpa.c | 45 +-
> > > > include/linux/virtio.h | 13 +-
> > > > include/linux/virtio_config.h | 48 +-
> > > > include/linux/virtio_ring.h | 82 +--
> > > > tools/virtio/virtio_test.c | 4 +-
> > > > tools/virtio/vringh_test.c | 28 +-
> > > > 17 files changed, 847 insertions(+), 625 deletions(-)
> > > >
> > > > --
> > > > 2.32.0.3.g01195cf9f
> > >
>
Powered by blists - more mailing lists