On 2021/3/20 3:45, Cong Wang wrote:
On Fri, Mar 19, 2021 at 2:25 AM Yunsheng Lin linyunsheng@huawei.com wrote:
I had done some performance test to see if there is value to fix the packet stuck problem and support lockless qdisc bypass, here is some result using pktgen in 'queue_xmit' mode on a dummy device as Paolo Abeni had done in [1], and using pfifo_fast qdisc:
threads vanilla locked-qdisc vanilla+this_patch 1 2.6Mpps 2.9Mpps 2.5Mpps 2 3.9Mpps 4.8Mpps 3.6Mpps 4 5.6Mpps 3.0Mpps 4.7Mpps 8 2.7Mpps 1.6Mpps 2.8Mpps 16 2.2Mpps 1.3Mpps 2.3Mpps
locked-qdisc: test by removing the "TCQ_F_NOLOCK | TCQ_F_CPUSTATS".
I read this as this patch introduces somehow a performance regression for -net, as the lockless bypass patch you submitted is for -net-next.
Yes, right now there is performance regression for fixing this bug, but the problem is that if we can not fix the above data race without any performance regression, do you prefer to send this patch to -net, or to -net-next with the lockless bypass patch?
Any idea to fix this with less performance regression?
Thanks.
.