Re: [RFC PATCH] ip: re-introduce fragments cache worker

[Eric Dumazet <eric.dumazet@gmail.com>]

On 07/09/2018 02:43 AM, Paolo Abeni wrote:
> On Fri, 2018-07-06 at 07:20 -0700, Eric Dumazet wrote:
>> I will test/polish it later, I am coming back from vacations and have a backlog.
>>
>> Here are my results : (Note that I have _not_ changed /proc/sys/net/ipv4/ipfrag_time )
>>
>> lpaa6:~# grep . /proc/sys/net/ipv4/ipfrag_* ; grep FRAG /proc/net/sockstat
>> /proc/sys/net/ipv4/ipfrag_high_thresh:104857600
>> /proc/sys/net/ipv4/ipfrag_low_thresh:78643200
>> /proc/sys/net/ipv4/ipfrag_max_dist:0
>> /proc/sys/net/ipv4/ipfrag_secret_interval:0
>> /proc/sys/net/ipv4/ipfrag_time:30
>> FRAG: inuse 1379 memory 105006776
>>
>> lpaa5:/export/hda3/google/edumazet# ./super_netperf 400 -H 10.246.7.134 -t UDP_STREAM -l 60
>> netperf: send_omni: send_data failed: No route to host
>> netperf: send_omni: send_data failed: No route to host
>>    9063
>>
>>
>> I would say that it looks pretty good to me.
> 
> Is that with an unmodifed kernel?
> 
> I would be happy if I could replicate such results. With the same
> configuration I see:
> 
> [netdev9 ~]# grep . /proc/sys/net/ipv4/ipfrag_*; nstat>/dev/null; sleep 1; nstat|grep IpR; grep FRAG /proc/net/sockstat
> /proc/sys/net/ipv4/ipfrag_high_thresh:104857600
> /proc/sys/net/ipv4/ipfrag_low_thresh:3145728
> /proc/sys/net/ipv4/ipfrag_max_dist:64
> /proc/sys/net/ipv4/ipfrag_secret_interval:0
> /proc/sys/net/ipv4/ipfrag_time:30
> IpReasmReqds                    827385             0.0
> IpReasmFails                    827385             0.0
> FRAG: inuse 1038 memory 105326208
> 
> [netdev8 ~]# ./super_netperf.sh 400 -H 192.168.101.2 -t UDP_STREAM -l 60 
> 213.6
> 
> Note: this setup is intentionally lossy (on the sender side), to stress
> the frag cache:
> 
> [netdev8 ~]#  tc -s qdisc show dev em1
> qdisc mq 8001: root 
>  Sent 73950097203 bytes 49639120 pkt (dropped 2052241, overlimits 0 requeues 41) 
>  backlog 0b 0p requeues 41 
> # ...
> 
> drops here are due to ldelay being higher than fq_codel's target (I use
> fq_codel default values). Can you please share your sender's TC conf
> and number of tx queues? 

You seem to self inflict losses on the sender, and that is terrible for the
(convoluted) stress test you want to run.

I use mq + fq : no losses on the sender.

Do not send patches to solve a problem that does not exist on the field.

If some customers are using netperf and UDP_STREAM with frags, just tell them to
use TCP instead :)