On Thu, 7 Mar 2024 08:50:21 -0800, Jakub Kicinski wrote:
> CC: Willem and some driver folks for more input, context: extending
> https://lore.kernel.org/all/20240306195509.1502746-1-k...@kernel.org/
> to cover virtio stats.
>
> On Tue, 27 Feb 2024 16:03:00 +0800 Xuan Zhuo wrote:
> > +static const
On Mon, 11 Mar 2024 18:48:45 +0800 Xuan Zhuo wrote:
> On Thu, 7 Mar 2024 08:50:21 -0800, Jakub Kicinski wrote:
> > CC: Willem and some driver folks for more input, context: extending
> > https://lore.kernel.org/all/20240306195509.1502746-1-k...@kernel.org/
> > to cover virtio stats.
> >
> > On Tue
As discussed:
http://lore.kernel.org/all/cacgkmevq0no8qgc46u4mgsmtud44fd_cflcpavmj3rhyqrz...@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. We can release the memory used
to store the dma info.
For
To make the code readable, introduce vring_need_unmap_buffer() to
replace do_unmap.
use_dma_api premapped -> vring_need_unmap_buffer()
1. false falsefalse
2. truefalsetrue
3. truetrue false
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drive
In the functions vring_unmap_one_split and
vring_unmap_one_split_indirect,
multiple checks are made whether unmap is performed and whether it is
INDIRECT.
These two functions are usually called in a loop, and we should put the
check outside the loop.
And we unmap the descs with VRING_DESC_F_INDIR
This commit structure the indirect desc table.
Then we can get the desc num directly when doing unmap.
And save the dma info to the struct, then the indirect
will not use the dma fields of the desc_extra. The subsequent
commits will make the dma fields are optional. But for
the indirect case, we m
In the functions vring_unmap_extra_packed and vring_unmap_desc_packed,
multiple checks are made whether unmap is performed and whether it is
INDIRECT.
These two functions are usually called in a loop, and we should put the
check outside the loop.
And we unmap the descs with VRING_DESC_F_INDIRECT
As discussed:
http://lore.kernel.org/all/CACGkMEug-=C+VQhkMYSgUKMC==04m7-uem_yc21bggkkzh8...@mail.gmail.com
When the vq is premapped mode, the driver manages the dma
info is a good way.
So this commit make the virtio core not to store the dma
info and release the memory which is used to store the
If the premapped mode is enabled, the dma array(struct vring_desc_dma) of
virtio core will not be allocated. That is judged when find_vqs() is
called. To avoid allocating dma array in find_vqs() and releasing it
immediately by virtqueue_set_dma_premapped(). This patch introduces a
new parameter to
Now, the API virtqueue_set_dma_premapped just support to
enable premapped mode.
If we allow enabling the premapped dynamically, we should
make this API to support disable the premapped mode.
Signed-off-by: Xuan Zhuo
---
drivers/virtio/virtio_ring.c | 34 ++
inclu
Now, the virtio core can set the premapped mode by find_vqs().
If the premapped can be enabled, the dma array will not be
allocated. So virtio-net use the api of find_vqs to enable the
premapped.
Judge the premapped mode by the vq->premapped instead of saving
local variable.
Signed-off-by: Xuan Z
This commit structure the indirect desc table.
Then we can get the desc num directly when doing unmap.
And save the dma info to the struct, then the indirect
will not use the dma fields of the desc_extra. The subsequent
commits will make the dma fields are optional. But for
the indirect case, we m
Export the premapped to drivers, then drivers can check
the vq premapped mode after the find_vqs().
Because the find_vqs() just try to enable the vq premapped mode,
the driver must check that after find_vqs().
Signed-off-by: Xuan Zhuo
---
drivers/virtio/virtio_ring.c | 13 +
include/
13 matches
Mail list logo
