netdev - Re: [PATCH net-next] udp: handle gro

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1f4bfef5.b4c7.16069879c26.Coremail.zhanglkk1990@163.com>
Date:   Mon, 18 Dec 2017 20:09:43 +0800 (CST)
From:   zhangliping <zhanglkk1990@....com>
To:     "Paolo Abeni" <pabeni@...hat.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        zhangliping <zhangliping02@...du.com>
Subject: Re: [PATCH net-next] udp: handle gro_receive only when necessary

Hi, 

At 2017-12-18 18:26:28, "Paolo Abeni" <pabeni@...hat.com> wrote:
>Hi,
>
>On Mon, 2017-12-18 at 12:11 +0800, zhangliping wrote:
>> From: zhangliping <zhangliping02@...du.com>
>> 
>> Under our udp pressure performance test, after gro is disabled, rx rate
>> will be improved from ~2500kpps to ~2800kpps. We can find some difference
>> from perf report:
>> 1. gro is enabled:
>>   24.23%   [kernel]       [k] udp4_lib_lookup2
>>    5.42%   [kernel]       [k] __memcpy
>>    3.87%   [kernel]       [k] fib_table_lookup
>>    3.76%   [kernel]       [k] __netif_receive_skb_core
>>    3.68%   [kernel]       [k] ip_rcv
>> 
>> 2. gro is disabled:
>>    9.66%   [kernel]       [k] udp4_lib_lookup2
>>    9.47%   [kernel]       [k] __memcpy
>>    4.75%   [kernel]       [k] fib_table_lookup
>>    4.71%   [kernel]       [k] __netif_receive_skb_core
>>    3.90%   [kernel]       [k] virtnet_poll
>> 
>> So if there's no udp tunnel(such as vxlan) configured, we can skip
>> the udp gro processing.
>
>I tested something similar some time ago, but I measured a much smaller
>gain. Also the topmost perf offenders looks quite different from what I
>see here, can you please share more details about the test case?

My test case is very simple, two VMs were connected via ovs + dpdk.
Inside VM, rps is enabled. Then one VM runs "iperf -s -u &", another
VM runs "iperf -c 1.1.1.2 -P 12 -u -b 10Gbps -l 40 -t 36000".

On the iperf server side, use the sar tool to watch the rx rate performance.

>> +DEFINE_STATIC_KEY_FALSE(udp_gro_needed);
>> +EXPORT_SYMBOL_GPL(udp_gro_needed);
>> +
>
>I think that adding a new static key is not required, as we can
>probably reuse 'udp_encap_needed' and 'udpv6_encap_needed'. The latter
>choice allows earlier branching (in
>udp4_gro_receive()/udp6_gro_receive() instead of udp_gro_receive().

Yes, we can reuse udpX_encap_needed, I indeed want to do like this at my
first attempt.

But I find some udp tunnel doesn't support gro receive(such as l2tp,
udp_media). And udpX_encap_needed won't be disabled after it is enabled,
at least for now.

So I finally chose to add a new udp_gro_needed, which seems a little redundant. :(