From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [RFC PATCH] ip: re-introduce fragments cache worker Date: Mon, 9 Jul 2018 04:34:10 -0700 Message-ID: <5909e281-8b4c-2cbc-3d55-c3f743885f1b@gmail.com> References: <6512d94713d40f1d572d2023168c48990f0d9cf0.1530798211.git.pabeni@redhat.com> <51ef14ac-1d98-ad75-d282-eb6cb177fe7a@gmail.com> <1df6b0ea-885b-7d5e-a0c9-e01a5a33a4f2@gmail.com> <8480556a-b0a3-5e1a-d1b7-726c52b52046@gmail.com> <83d36724c67d89f3cecec70f45179160653a2c01.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: "David S. Miller" , Eric Dumazet , Florian Westphal , NeilBrown To: Paolo Abeni , Eric Dumazet , netdev@vger.kernel.org Return-path: Received: from mail-pf0-f196.google.com ([209.85.192.196]:36360 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932419AbeGILeN (ORCPT ); Mon, 9 Jul 2018 07:34:13 -0400 Received: by mail-pf0-f196.google.com with SMTP id u16-v6so13483155pfh.3 for ; Mon, 09 Jul 2018 04:34:13 -0700 (PDT) In-Reply-To: <83d36724c67d89f3cecec70f45179160653a2c01.camel@redhat.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 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 :)