Re: [PATCH 00/33] virtio-net: support AF_XDP zero copy

On Fri, Feb 03, 2023 at 09:46:46AM +0100, Maciej Fijalkowski wrote:

On Fri, Feb 03, 2023 at 03:37:32AM -0500, Michael S. Tsirkin wrote:

quoted

On Fri, Feb 03, 2023 at 11:33:31AM +0800, Xuan Zhuo wrote:

quoted

On Thu, 02 Feb 2023 15:41:44 +0100, Paolo Abeni [off-list ref] wrote:

quoted

On Thu, 2023-02-02 at 19:00 +0800, Xuan Zhuo wrote:

quoted

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. mlx5 and intel ixgbe already support
this feature, This patch set allows virtio-net to support xsk's zerocopy xmit
feature.

Virtio-net did not support per-queue reset, so it was impossible to support XDP
Socket Zerocopy. At present, we have completed the work of Virtio Spec and
Kernel in Per-Queue Reset. It is time for Virtio-Net to complete the support for
the XDP Socket Zerocopy.

Virtio-net can not increase the queue at will, so xsk shares the queue with
kernel.

On the other hand, Virtio-Net does not support generate interrupt manually, so
when we wakeup tx xmit, we used some tips. If the CPU run by TX NAPI last time
is other CPUs, use IPI to wake up NAPI on the remote CPU. If it is also the
local CPU, then we wake up sofrirqd.

Thank you for the large effort.

Since this will likely need a few iterations, on next revision please
do split the work in multiple chunks to help the reviewer efforts -
from Documentation/process/maintainer-netdev.rst:

 - don't post large series (> 15 patches), break them up

In this case I guess you can split it in 1 (or even 2) pre-req series
and another one for the actual xsk zero copy support.

OK.

I can split patch into multiple parts such as

* virtio core
* xsk
* virtio-net prepare
* virtio-net support xsk zerocopy

However, there is a problem, the virtio core part should enter the VHOST branch
of Michael. Then, should I post follow-up patches to which branch vhost or
next-next?

Thanks.

I personally think 33 patches is still manageable no need to split.
Do try to be careful and track acks and changes: if someone sends an ack
add it in the patch if you change the patch drop the acks,
and logs this fact in the changelog in the cover letter
so people know they need to re-review.

To me some of the patches are too granular but probably this is related to
personal taste.

I agree here. Some unrelated refactoring can also be deferred.

However, I would like to ask to check how this series
affects existing ZC enabled driver(s), since xsk core is touched.

quoted

quoted

quoted

Thanks!

Paolo