Hi, 

At 2017-12-18 18:26:28, "Paolo Abeni" <pab...@redhat.com> wrote:
>Hi,
>
>On Mon, 2017-12-18 at 12:11 +0800, zhangliping wrote:
>> From: zhangliping <zhanglipin...@baidu.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. 
:(

Reply via email to