Re: [PATCH net-next 00/17] virtio-net: support AF_XDP zero copy (3/3)

2024-01-21 Thread Jason Wang
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)

2024-01-16 Thread Xuan Zhuo
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)

2024-01-16 Thread Xuan Zhuo
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)

2024-01-16 Thread Michael S. Tsirkin
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)

2024-01-16 Thread Jakub Kicinski
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)

2024-01-16 Thread Paolo Abeni
  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