From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 22E2C3B29E for ; Fri, 29 Oct 2021 11:41:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1635522061; bh=s6STL8tBNSM/wZizCJHwUP8PegB6jtRgt6zeItjJiF4=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=YHN3BseggWqERWZW5TUF42j75By0Xe87XuZ5/M4owySC3tQXUVfGtibQv1vW3/j7U kgSRmFpJxdrtCrUo9Ibt23wgTT/Q25SGOMvXUZ17i1wGuW+oBLsV8oxnYMH9Hl+O5u zT01OvSddGu3NwONN4ZpoCGXaf+sm710FghD5jxM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MJmGP-1mN2P60c2r-00K5TV; Fri, 29 Oct 2021 17:41:01 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 29 Oct 2021 17:41:00 +0200 Cc: ECN-Sane Content-Transfer-Encoding: quoted-printable Message-Id: <928A61C5-FFA2-43AE-8461-48AFA93C1B78@gmx.de> References: <20211028191500.47377-1-asadsa@ifi.uio.no> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Provags-ID: V03:K1:gT3P22ZY9cgOuBbNnZ8asFYi+eLWWAt2e3rTAXLfgU5J+uiuJMP FBZzpMXi14IFMfhJ5HU7iB3dECSlHtQu9Id95ybY89qDJ/DmIBTYnnWaQ9v0M9zRXQMij1O NqOwF8JyFM46/81+rd10oC90vucX5a4yV3NcplnDFoSPOWM7HXYy0ap4beqSX6ejrKwpLzH sGpDtsXygi+p7+U7G/72g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:MwrY99wMAUM=:F2xBkFk603DYKt+sOkh5d0 2G8jbLR16A3xHfpiy0CSZpVGgzqBvXAFYuQWa2eoF+SU+7DmKjNL+yUP44n3wbKiOl+Rh/Kux XxhTTDfCL8WrWj3OTL10gSBLRH3GkAqC0aoO15Pl6PeUgRmDVOBrrRZXegpcmgCSbT/CD9ZUY +TFXQxMdzF1zf45uUKTJKIjlQxr9pTDtoCjBJizgd557G+SaoECp7EFvXEHvAMpd5TnEuSYie rDcy2cDpcJoHSL4rd/5jEciEBcM6TCKoA+w2WAse5iU9/kZD+kUEr+PiFeNCfmUZh/NTbdSWc bUbZgri371vIySqj4xHqjIoM1DfFFs5tSLnzWToCrTLfD9208Mk4OKqVivjm5dchqFH7Tgjg3 3URlc/LK80Dg5Y7vZNlQF1lxwO8BdkwQ/uAGMG57rIYdQq4Ind9deeU6ev6c7+kVqpzF7697r Yc6JAUtNb9t7rN54w0IB3Apk/JIfZ4PV9G07ibUkht5XE9Rqm7GkCbSzIZonoqUuY3DumOjWq AnI9/uE6SYQagO7jvy9YjJpPm7ZdCxzvGlUcqLjcad7yLczCaA6z14GNQEQbqv9bCRdH0zEPf Zraw63ZJSEGEvHzma3gEwkn6jq0cUSA4XKJ4w/XEi7+zKKXJ4Dr1S1zlnuYk9Zv7cjUvJKHmQ ySE+Yx3RtHXZl+O9BLR+DdgH/xvugp7AfX47ls7rdoSxe9vLW4jdHGDJzSMOFORYdrLrdjB6S z1xOklkje2QAp+RpSKXztmMu51YGaqYVqVUTDAM0aZAx/5t8R4Cb0PsBuvyB8kDJc3vH8sPqw ArJxsTnzsSNr9H/F1bNvy94RczIU0FUIlD3y/5mnf0IiLhsnB7tWXNFPuaMCo8i38HXo9/Bp6 +yEZpp5qEVMwPkiOSroGW74sfmtk9sIyl9KE2PJLVD+inUoOniso4avb7dQEXCKLCn16VCWpm e/ZxHX6tQrpndVvPyQtjteee9RGBnyWbi9s9sjBA/Datd4sJhvFZXNObIrGIq63qrzJIim4/z KGP6aR9N83ZAo87Sh8emV0oBBC6vGRYZAg1iGGRvje/cqEpX/Zl427c0q75U47sTfZsAM5K+e zAhMPukoA7+o4o= Subject: Re: [Ecn-sane] [PATCH net-next] fq_codel: avoid under-utilization with ce_threshold at low link rates X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 15:41:03 -0000 How is that different from setting the threshold to be equivalent to one = packets transmission time (or slightly above). I guess for smaller than = MTU packets this might make a difference, but which source is going to = produce them back to back so that paying attention actually has some = benefit? My gut-feeling is that this just helps to keep a nice feeling because = the threshold is nice and small, even though effectively it is not... = What am I missing here? Regards Sebastian > On Oct 29, 2021, at 17:22, Dave Taht wrote: >=20 > ---------- Forwarded message --------- > From: Eric Dumazet > Date: Fri, Oct 29, 2021 at 7:53 AM > Subject: Re: [PATCH net-next] fq_codel: avoid under-utilization with > ce_threshold at low link rates > To: Neal Cardwell > Cc: Asad Sajjad Ahmed , David S. Miller > , Jakub Kicinski , netdev > , Toke H=C3=B8iland-J=C3=B8rgensen = , > Ingemar Johansson S , Tom Henderson > , Bob Briscoe , Olga Albisser > >=20 >=20 > On Fri, Oct 29, 2021 at 6:54 AM Neal Cardwell = wrote: >>=20 >> On Thu, Oct 28, 2021 at 3:15 PM Asad Sajjad Ahmed = wrote: >>>=20 >>> Commit "fq_codel: generalise ce_threshold marking for subset of = traffic" >>> [1] enables ce_threshold to be used in the Internet, not just in = data >>> centres. >>>=20 >>> Because ce_threshold is in time units, it can cause poor utilization = at >>> low link rates when it represents <1 packet. >>> E.g., if link rate <12Mb/s ce_threshold=3D1ms is <1500B packet. >>>=20 >>> So, suppress ECN marking unless the backlog is also > 1 MTU. >>>=20 >>> A similar patch to [1] was tested on an earlier kernel, and a = similar >>> one-packet check prevented poor utilization at low link rates [2]. >>>=20 >>> [1] commit dfcb63ce1de6 ("fq_codel: generalise ce_threshold marking = for subset of traffic") >>>=20 >>> [2] See right hand column of plots at the end of: >>> = https://bobbriscoe.net/projects/latency/dctth_journal_draft20190726.pdf >>>=20 >>> Signed-off-by: Asad Sajjad Ahmed >>> Signed-off-by: Olga Albisser >>> --- >>> include/net/codel_impl.h | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>=20 >>> diff --git a/include/net/codel_impl.h b/include/net/codel_impl.h >>> index 137d40d8cbeb..4e3e8473e776 100644 >>> --- a/include/net/codel_impl.h >>> +++ b/include/net/codel_impl.h >>> @@ -248,7 +248,8 @@ static struct sk_buff *codel_dequeue(void *ctx, >>> = vars->rec_inv_sqrt); >>> } >>> end: >>> - if (skb && codel_time_after(vars->ldelay, = params->ce_threshold)) { >>> + if (skb && codel_time_after(vars->ldelay, = params->ce_threshold) && >>> + *backlog > params->mtu) { >=20 > I think this idea would apply to codel quite well. (This helper is > common to codel and fq_codel) >=20 > But with fq_codel my thoughts are: >=20 > *backlog is the backlog of the qdisc, not the backlog for the flow, > and it includes the packet currently being removed from the queue. >=20 > Setting ce_threshold to 1ms while the link rate is 12Mbs sounds > misconfiguration to me. >=20 > Even if this flow has to transmit one tiny packet every minute, it > will get CE mark > just because at least one packet from an elephant flow is currently > being sent to the wire. >=20 > BQL won't prevent that at least one packet is being processed while > the tiny packet > is coming into fq_codel qdisc. >=20 > vars->ldelay =3D now - skb_time_func(skb); >=20 > For tight ce_threshold, vars->ldelay would need to be replaced by >=20 > now - (time of first codel_dequeue() after this skb has been queued). > This seems a bit hard to implement cheaply. >=20 >=20 >=20 >=20 >>> bool set_ce =3D true; >>>=20 >>> if (params->ce_threshold_mask) { >>> -- >>=20 >> Sounds like a good idea, and looks good to me. >>=20 >> Acked-by: Neal Cardwell >>=20 >> Eric, what do you think? >>=20 >> neal >=20 >=20 > --=20 > Fixing Starlink's Latencies: = https://www.youtube.com/watch?v=3Dc9gLo6Xrwgw >=20 > Dave T=C3=A4ht CEO, TekLibre, LLC > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane