Re: [PATCH net-next 00/17] virtio-net: support AF_XDP zero copy (3/3)
On Wed, Jan 17, 2024 at 1:58 PM Xuan Zhuo wrote: > > On Tue, 16 Jan 2024 07:07:05 -0800, Jakub Kicinski wrote: > > On Tue, 16 Jan 2024 13:37:30 +0100 Paolo Abeni wrote: > > > For future submission it would be better if you split this series in > > > smaller chunks: the maximum size allowed is 15 patches. > > > > Which does not mean you can split it up and post them all at the same > > time, FWIW. > > > I hope some ones have time to reivew the other parts. Will review those this week. Thanks > In the future, I will post one after the last one is merged. > > Thanks. >
Re: [PATCH net-next 00/17] virtio-net: support AF_XDP zero copy (3/3)
On Tue, 16 Jan 2024 07:07:05 -0800, Jakub Kicinski wrote: > On Tue, 16 Jan 2024 13:37:30 +0100 Paolo Abeni wrote: > > For future submission it would be better if you split this series in > > smaller chunks: the maximum size allowed is 15 patches. > > Which does not mean you can split it up and post them all at the same > time, FWIW. I hope some ones have time to reivew the other parts. In the future, I will post one after the last one is merged. Thanks.
Re: [PATCH net-next 00/17] virtio-net: support AF_XDP zero copy (3/3)
On Tue, 16 Jan 2024 15:46:00 -0500, "Michael S. Tsirkin" wrote: > On Tue, Jan 16, 2024 at 07:07:05AM -0800, Jakub Kicinski wrote: > > On Tue, 16 Jan 2024 13:37:30 +0100 Paolo Abeni wrote: > > > For future submission it would be better if you split this series in > > > smaller chunks: the maximum size allowed is 15 patches. > > > > Which does not mean you can split it up and post them all at the same > > time, FWIW. > > > Really it's just 17 I don't think it matters. Some patches could be > squashed easily but I think that would be artificial. Yes. About this patch set I think a lot. This is the core code for the function. I think we should not split it. And some commits are simply. Thanks. >
Re: [PATCH net-next 00/17] virtio-net: support AF_XDP zero copy (3/3)
On Tue, Jan 16, 2024 at 07:07:05AM -0800, Jakub Kicinski wrote: > On Tue, 16 Jan 2024 13:37:30 +0100 Paolo Abeni wrote: > > For future submission it would be better if you split this series in > > smaller chunks: the maximum size allowed is 15 patches. > > Which does not mean you can split it up and post them all at the same > time, FWIW. Really it's just 17 I don't think it matters. Some patches could be squashed easily but I think that would be artificial.
Re: [PATCH net-next 00/17] virtio-net: support AF_XDP zero copy (3/3)
On Tue, 16 Jan 2024 13:37:30 +0100 Paolo Abeni wrote: > For future submission it would be better if you split this series in > smaller chunks: the maximum size allowed is 15 patches. Which does not mean you can split it up and post them all at the same time, FWIW.
Re: [PATCH net-next 00/17] virtio-net: support AF_XDP zero copy (3/3)
On Tue, 2024-01-16 at 17:42 +0800, Xuan Zhuo wrote: > This is the third part of virtio-net support AF_XDP zero copy. > > The whole patch set > http://lore.kernel.org/all/20231229073108.57778-1-xuanz...@linux.alibaba.com > > ## AF_XDP > > 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. > > At present, we have completed some preparation: > > 1. vq-reset (virtio spec and kernel code) > 2. virtio-core premapped dma > 3. virtio-net xdp refactor > > So it is time for Virtio-Net to complete the support for the XDP Socket > Zerocopy. > > Virtio-net can not increase the queue num at will, so xsk shares the queue > with > kernel. > > On the other hand, Virtio-Net does not support generate interrupt from driver > 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 napi directly. > > This patch set includes some refactor to the virtio-net to let that to support > AF_XDP. > > ## performance > > ENV: Qemu with vhost-user(polling mode). > Host CPU: Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz > > ### virtio PMD in guest with testpmd > > testpmd> show port stats all > > NIC statistics for port 0 > RX-packets: 19531092064 RX-missed: 0 RX-bytes: 1093741155584 > RX-errors: 0 > RX-nombuf: 0 > TX-packets: 595992 TX-errors: 0 TX-bytes: 371030645664 > > > Throughput (since last show) > Rx-pps: 8861574 Rx-bps: 3969985208 > Tx-pps: 8861493 Tx-bps: 3969962736 > > > ### AF_XDP PMD in guest with testpmd > > testpmd> show port stats all > > NIC statistics for port 0 > RX-packets: 68152727 RX-missed: 0 RX-bytes: 3816552712 > RX-errors: 0 > RX-nombuf: 0 > TX-packets: 68114967 TX-errors: 33216 TX-bytes: 3814438152 > > Throughput (since last show) > Rx-pps: 6333196 Rx-bps: 2837272088 > Tx-pps: 6333227 Tx-bps: 2837285936 > > > But AF_XDP consumes more CPU for tx and rx napi(100% and 86%). > > ## maintain > > I am currently a reviewer for virtio-net. I commit to maintain AF_XDP support > in > virtio-net. > > Please review. > > Thanks. For future submission it would be better if you split this series in smaller chunks: the maximum size allowed is 15 patches. ## Form letter - net-next-closed The merge window for v6.8 has begun and we have already posted our pull request. Therefore net-next is closed for new drivers, features, code refactoring and optimizations. We are currently accepting bug fixes only. Please repost when net-next reopens after January 22nd. RFC patches sent for review only are obviously welcome at any time. See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle -- pw-bot: defer
[PATCH net-next 00/17] virtio-net: support AF_XDP zero copy (3/3)
This is the third part of virtio-net support AF_XDP zero copy. The whole patch set http://lore.kernel.org/all/20231229073108.57778-1-xuanz...@linux.alibaba.com ## AF_XDP 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. At present, we have completed some preparation: 1. vq-reset (virtio spec and kernel code) 2. virtio-core premapped dma 3. virtio-net xdp refactor So it is time for Virtio-Net to complete the support for the XDP Socket Zerocopy. Virtio-net can not increase the queue num at will, so xsk shares the queue with kernel. On the other hand, Virtio-Net does not support generate interrupt from driver 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 napi directly. This patch set includes some refactor to the virtio-net to let that to support AF_XDP. ## performance ENV: Qemu with vhost-user(polling mode). Host CPU: Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz ### virtio PMD in guest with testpmd testpmd> show port stats all NIC statistics for port 0 RX-packets: 19531092064 RX-missed: 0 RX-bytes: 1093741155584 RX-errors: 0 RX-nombuf: 0 TX-packets: 595992 TX-errors: 0 TX-bytes: 371030645664 Throughput (since last show) Rx-pps: 8861574 Rx-bps: 3969985208 Tx-pps: 8861493 Tx-bps: 3969962736 ### AF_XDP PMD in guest with testpmd testpmd> show port stats all NIC statistics for port 0 RX-packets: 68152727 RX-missed: 0 RX-bytes: 3816552712 RX-errors: 0 RX-nombuf: 0 TX-packets: 68114967 TX-errors: 33216 TX-bytes: 3814438152 Throughput (since last show) Rx-pps: 6333196 Rx-bps: 2837272088 Tx-pps: 6333227 Tx-bps: 2837285936 But AF_XDP consumes more CPU for tx and rx napi(100% and 86%). ## maintain I am currently a reviewer for virtio-net. I commit to maintain AF_XDP support in virtio-net. Please review. Thanks. v3 1. virtio introduces helpers for virtio-net sq using premapped dma 2. xsk has more complete support for merge mode 3. fix some problems v2 1. wakeup uses the way of GVE. No send ipi to wakeup napi on remote cpu. 2. remove rcu. Because we synchronize all operat, so the rcu is not needed. 3. split the commit "move to virtio_net.h" in last patch set. Just move the struct/api to header when we use them. 4. add comments for some code v1: 1. remove two virtio commits. Push this patchset to net-next 2. squash "virtio_net: virtnet_poll_tx support rescheduled" to xsk: support tx 3. fix some warnings Xuan Zhuo (17): virtio_net: separate virtnet_rx_resize() virtio_net: separate virtnet_tx_resize() virtio_net: xsk: bind/unbind xsk virtio_net: xsk: prevent disable tx napi virtio_net: move some api to header virtio_net: xsk: tx: support xmit xsk buffer virtio_net: xsk: tx: support wakeup virtio_net: xsk: tx: handle the transmitted xsk buffer virtio_net: xsk: tx: free the unused xsk buffer virtio_net: separate receive_mergeable virtio_net: separate receive_buf virtio_net: xsk: rx: support fill with xsk buffer virtio_net: xsk: rx: support recv merge mode virtio_net: xsk: rx: support recv small mode virtio_net: xsk: rx: free the unused xsk buffer virtio_net: update tx timeout record virtio_net: xdp_features add NETDEV_XDP_ACT_XSK_ZEROCOPY drivers/net/virtio/Makefile | 2 +- drivers/net/virtio/main.c | 409 +++-- drivers/net/virtio/virtio_net.h | 140 +++ drivers/net/virtio/xsk.c| 622 drivers/net/virtio/xsk.h| 32 ++ 5 files changed, 1014 insertions(+), 191 deletions(-) create mode 100644 drivers/net/virtio/xsk.c create mode 100644 drivers/net/virtio/xsk.h -- 2.32.0.3.g01195cf9f
