On Tue, 7 Mar 2023 15:39:45 +0800, Xuan Zhuo wrote:
> On Tue, 7 Mar 2023 14:43:42 +0800, Jason Wang wrote:
> > On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
> > >
> > > virtqueue_add_split() only supports virtual addresses, dma is completed
> > > in virtqueue_add_split().
> > >
> > > In some s
On Tue, 7 Mar 2023 14:43:42 +0800, Jason Wang wrote:
> On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
> >
> > virtqueue_add_split() only supports virtual addresses, dma is completed
> > in virtqueue_add_split().
> >
> > In some scenarios (such as the AF_XDP scenario), the memory is allocated
> >
On Mon, Mar 6, 2023 at 3:48 PM Alvaro Karsz wrote:
>
> > Is this too late to be changed?
> >
> > Thanks
>
> You're right.
> What do you suggest, dropping the patch or adding the unified struct without
> deleting the existing ones?
At least we need to avoid touching existing uAPI structures.
I t
On Tue, 7 Mar 2023 14:43:58 +0800, Jason Wang wrote:
> On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
> >
> > The subsequent reset function will reuse these logic.
> >
> > Signed-off-by: Xuan Zhuo
> > ---
> > drivers/virtio/virtio_ring.c | 58
> > 1 file ch
On Tue, 7 Mar 2023 14:43:49 +0800, Jason Wang wrote:
> On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
> >
> > This commit splits virtqueue_add_packed() to two functions. The purpose
> > of such splitting is to separate DMA operations.
> >
> > The first function includes all codes that may fail b
On Tue, 7 Mar 2023 14:43:45 +0800, Jason Wang wrote:
> On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
> >
> > Separating the logic of allocating indirect desc and checking queue
> > status to the upper layer function.
>
> Note that it looks to me it's not logic separation but a simple moving.
On Tue, 7 Mar 2023 14:43:42 +0800, Jason Wang wrote:
> On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
> >
> > virtqueue_add_split() only supports virtual addresses, dma is completed
> > in virtqueue_add_split().
> >
> > In some scenarios (such as the AF_XDP scenario), the memory is allocated
> >
On Tue, 7 Mar 2023 14:43:39 +0800, Jason Wang wrote:
> On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
> >
> > DMA-related logic is separated from the virtqueue_add_vring_split() to
> > prepare for subsequent support for premapped.
> >
> > DMA address will be saved as sg->dma_address, then
> > vi
On Tue, 7 Mar 2023 14:43:35 +0800, Jason Wang wrote:
> On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
> >
> > This commit splits virtqueue_add_split() to two functions. The purpose
> > of such splitting is to separate DMA operations.
> >
> > The first function includes all codes that may fail be
On Mon, Mar 6, 2023 at 7:33 PM Eugenio Perez Martin wrote:
>
> On Mon, Mar 6, 2023 at 4:42 AM Jason Wang wrote:
> >
> > On Fri, Mar 3, 2023 at 4:58 PM Eugenio Perez Martin
> > wrote:
> > >
> > > On Fri, Mar 3, 2023 at 4:48 AM Jason Wang wrote:
> > > >
> > > >
> > > > 在 2023/3/2 03:32, Eugenio
On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
>
> The subsequent reset function will reuse these logic.
>
> Signed-off-by: Xuan Zhuo
> ---
> drivers/virtio/virtio_ring.c | 58
> 1 file changed, 39 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/virt
On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
>
> DMA-related logic is separated from the virtqueue_add_vring_packed() to
> prepare for subsequent support for premapped.
>
> DMA address will be saved as sg->dma_address, then
> virtqueue_add_vring_packed() will use it directly.
>
> If it is a pre
On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
>
> Added virtqueue_get_dma_dev() to get DMA device for virtio. Then the
> caller can do dma operation in advance. The purpose is to keep memory
> mapped across multiple add/get buf operations.
>
> Signed-off-by: Xuan Zhuo
> ---
> drivers/virtio/vi
On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
>
> This commit splits virtqueue_add_packed() to two functions. The purpose
> of such splitting is to separate DMA operations.
>
> The first function includes all codes that may fail before the DMA
> operation. The subsequent part is used as the seco
On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
>
> DMA-related logic is separated from the virtqueue_add_vring_split() to
> prepare for subsequent support for premapped.
>
> DMA address will be saved as sg->dma_address, then
> virtqueue_add_vring_split() will use it directly.
>
> If it is a prema
On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
>
> Separating the logic of allocating indirect desc and checking queue
> status to the upper layer function.
Note that it looks to me it's not logic separation but a simple moving.
>
> The proposal of this is convenient to refactor virtqueue_add_
On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
>
> virtqueue_add_split() only supports virtual addresses, dma is completed
> in virtqueue_add_split().
>
> In some scenarios (such as the AF_XDP scenario), the memory is allocated
> and DMA is completed in advance, so it is necessary for us to suppo
On Thu, Mar 2, 2023 at 7:59 PM Xuan Zhuo wrote:
>
> This commit splits virtqueue_add_split() to two functions. The purpose
> of such splitting is to separate DMA operations.
>
> The first function includes all codes that may fail before the DMA
> operation. The subsequent part is used as the secon
Add const to make the read-only pointer parameters clear, similar to
many existing functions.
Signed-off-by: Feng Liu
Reviewed-by: Jiri Pirko
Reviewed-by: Parav Pandit
Reviewed-by: Gavin Li
Reviewed-by: Bodong Wang
---
drivers/virtio/virtio_ring.c | 25 -
include/linu
According to kernel coding style [1], defining inline functions is not
necessary and beneficial for simple functions. Hence clean up the code
by removing the inline keyword.
It is verified with GCC 12.2.0, the generated code with/without inline
is same. Additionally tested with pktgen and iperf, a
This patch series performs a clean up of the code in virtio_ring and
virtio_pci, modifying it to conform with the Linux kernel coding style
guidance [1]. The modifications ensure the code easy to read and
understand. This small series does few short cleanups in the code.
Patch-1 Remove unnecessary
is_power_of_2() already performs the zero check. Hence avoid duplicate
check. While at it, move the query of size check also adjacent to where
its used for the disabled vq.
Signed-off-by: Feng Liu
Reviewed-by: Jiri Pirko
Reviewed-by: Parav Pandit
Reviewed-by: Gavin Li
Reviewed-by: Bodong Wang
On Mon, 6 Mar 2023 12:58:22 -0500, "Michael S. Tsirkin" wrote:
> On Mon, Mar 06, 2023 at 12:15:33PM +0800, Xuan Zhuo wrote:
> > If the queue of xdp xmit is not an independent queue, then when the xdp
> > xmit used all the desc, the xmit from the __dev_queue_xmit() may encounter
> > the following e
On Mon, 6 Mar 2023 12:57:34 -0500, "Michael S. Tsirkin" wrote:
> On Mon, Mar 06, 2023 at 12:15:35PM +0800, Xuan Zhuo wrote:
> > If the queue of xdp xmit is not an independent queue, then when the xdp
> > xmit used all the desc, the xmit from the __dev_queue_xmit() may encounter
> > the following e
On Mon, Mar 06, 2023 at 12:15:33PM +0800, Xuan Zhuo wrote:
> If the queue of xdp xmit is not an independent queue, then when the xdp
> xmit used all the desc, the xmit from the __dev_queue_xmit() may encounter
> the following error.
>
> net ens4: Unexpected TXQ (0) queue failure: -28
>
> This pat
On Mon, Mar 06, 2023 at 12:15:35PM +0800, Xuan Zhuo wrote:
> If the queue of xdp xmit is not an independent queue, then when the xdp
> xmit used all the desc, the xmit from the __dev_queue_xmit() may encounter
> the following error.
>
> net ens4: Unexpected TXQ (0) queue failure: -28
>
> This pat
On Mon, 2023-03-06 at 12:15 +0800, Xuan Zhuo wrote:
> If the queue of xdp xmit is not an independent queue, then when the xdp
> xmit used all the desc, the xmit from the __dev_queue_xmit() may encounter
> the following error.
>
> net ens4: Unexpected TXQ (0) queue failure: -28
>
> This patch adds
On Mon, Mar 06, 2023 at 07:00:10PM +0300, Arseniy Krasnov wrote:
On 06.03.2023 18:51, Stefano Garzarella wrote:
On Mon, Mar 06, 2023 at 06:31:22PM +0300, Arseniy Krasnov wrote:
On 06.03.2023 15:08, Stefano Garzarella wrote:
On Sun, Mar 05, 2023 at 11:07:37PM +0300, Arseniy Krasnov wrote:
On Mon, Mar 06, 2023 at 06:31:22PM +0300, Arseniy Krasnov wrote:
On 06.03.2023 15:08, Stefano Garzarella wrote:
On Sun, Mar 05, 2023 at 11:07:37PM +0300, Arseniy Krasnov wrote:
In case of SOCK_SEQPACKET all sk_buffs are used once - after read some
data from it, it will be removed, so user wil
On Mon, Mar 06, 2023 at 05:32:34PM +0300, Dmitry Osipenko wrote:
> VirtIO-GPU got a new config option for disabling KMS. There were two
> problems left unnoticed during review when the new option was added:
>
> 1. The IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS) check in the code was
> inverted, hence KM
On Sun, Mar 05, 2023 at 11:07:37PM +0300, Arseniy Krasnov wrote:
In case of SOCK_SEQPACKET all sk_buffs are used once - after read some
data from it, it will be removed, so user will never read rest of the
data. Thus we need to update credit parameters of the socket like whole
sk_buff is read - s
On Sun, Mar 05, 2023 at 11:08:38PM +0300, Arseniy Krasnov wrote:
This fixes two things in case when 'memcpy_to_msg()' fails:
1) Update credit parameters of the socket, like this skbuff was
copied to user successfully. This is needed because when skbuff was
received it's length was used to upd
On Sun, Mar 05, 2023 at 11:06:26PM +0300, Arseniy Krasnov wrote:
Substraction of 'skb->len' is redundant here: 'skb_headroom()' is delta
between 'data' and 'head' pointers, e.g. it is number of bytes returned
to user (of course accounting size of header). 'skb->len' is number of
bytes rest in buf
On Sun, 5 Mar 2023 04:53:58 -0500, "Michael S. Tsirkin" wrote:
> On Fri, Mar 03, 2023 at 04:46:03PM -0800, Jakub Kicinski wrote:
> > On Thu, 2 Mar 2023 04:48:38 -0500 Michael S. Tsirkin wrote:
> > > > Looks not the core can try to enable and disable features according to
> > > > the diff between f
On Thu, Feb 23, 2023 at 04:05:51PM +0100, Juergen Gross wrote:
> x86 maintainers, I think this patch should be carried via the tip tree.
You missed a spot. I'll whack it.
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index a8b323266179..c3ad8a526378 100644
35 matches
Mail list logo
