From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 62F1320175A for ; Thu, 14 May 2015 15:07:00 -0700 (PDT) Received: by lagv1 with SMTP id v1so89183286lag.3 for ; Thu, 14 May 2015 15:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2N4nSM4x7ZHt56gvcNycH8IfBXcMELQAT1HZxC6DTco=; b=p08Z3mQpODJxvFwBr12MEm9k6fQihPHtYUJDDvFx0E/4x0ffNb5C6KkBUymDmb787r osehKAmIuu3xUTuXLjGrKFbjMqdgYom3ZK6JeOx0yVdR8EoF2fPdBlo84GggcxlqceTz fH1Hfp871tOOnDh5OByglj2PLGUOfhU+c434dobTrY3hKe5GHtwihFKAB/C41VGoAbhX a4bFL+l8My1beXV+BZKYPGK74rJgEmoydIZ0VB4dYTaH64K6jYIpBFHMtnbEDGuDeL8H w2quuFtFgHBZ6n2gExQ8WVO1WJFkyQq+rCdpZvumAty+gjPnNzA8eS8cXI8xgHvbI+Gb 8xiA== X-Received: by 10.112.166.37 with SMTP id zd5mr4529764lbb.75.1431641206924; Thu, 14 May 2015 15:06:46 -0700 (PDT) Received: from bass.home.chromatix.fi (87-93-34-32.bb.dnainternet.fi. [87.93.34.32]) by mx.google.com with ESMTPSA id oy3sm108119lbb.1.2015.05.14.15.06.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 15:06:46 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: Date: Fri, 15 May 2015 01:06:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5334C435-218A-48CF-8AB2-F73F76F47216@gmail.com> References: <554F64E1.6000609@gmail.com> <554F9594.60808@gmail.com> <50DB1E31-61AE-4298-B80F-8C6F7487C99B@gmail.com> <002A5BFC-5511-4995-8785-370251F24083@gmx.de> <38FFDA3C-2F67-4831-B316-DF8CC7EF0167@gmail.com> <664C6B9D-67C2-4614-A9B0-140D3BEEA4AD@gmx.de> <444770E9-51C0-4935-8E00-5008CDB388E5@gmail.com> To: Sebastian Moeller X-Mailer: Apple Mail (2.2098) Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] openwrt build with latest cake and other qdiscs X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 22:08:20 -0000 > On 14 May, 2015, at 21:15, Sebastian Moeller wrote: >=20 > I guess your idea of peeling for ATM carrier and for >1ms wire time = aggregates sounds like a decent idea=85 Code review time, then: /* * We tolerate GSO aggregates if they occupy < 1ms of wire time * AND we don't need to perform ATM cell-framing. We're = unlikely * to need the latter above 24Mbps (best ADSL downlink), where * handling individual packets is still cheap. * * But if those conditions aren't met, we need to split it. */ if(unlikely(len > (q->rate_bps >> 10) || (q->rate_flags & CAKE_FLAG_ATM)) && skb_is_gso(skb)) { struct sk_buff *segs, *nskb; netdev_features_t features =3D netif_skb_features(skb); int ret =3D NET_XMIT_DROP; segs =3D skb_gso_segment(skb, features & = ~NETIF_F_GSO_MASK); if (IS_ERR_OR_NULL(segs)) return qdisc_reshape_fail(skb, sch); while (segs) { nskb =3D segs->next; segs->next =3D NULL; qdisc_skb_cb(segs)->pkt_len =3D segs->len; switch(cake_enqueue(segs, sch)) { case NET_XMIT_CN: ret =3D NET_XMIT_CN; /* fall */ case NET_XMIT_SUCCESS: if(ret =3D=3D NET_XMIT_DROP) ret =3D = NET_XMIT_SUCCESS; qdisc_tree_decrease_qlen(sch, = -1); /* fall */ default:; } segs =3D nskb; } qdisc_tree_decrease_qlen(sch, 1); consume_skb(skb); return ret; } I=92m thinking of inserting the above into the beginning of = cake_enqueue(). This of course makes it a recursive function (but only = by one level). A bit of lateral thinking was necessary to convert the equivalent code = in TBF (which relies on a child qdisc to do the actual queuing) into a = form that cake could use, so I=92m not pushing it to git until someone = can spot what, if anything, I=92ve got horribly wrong. However, it does = compile and doesn=92t seem to crash when I run it on a box with GSO = turned on, so it=92s probably worth a cautious try. One quirk is that, in its current form, it=92ll *always* peel GSO = aggregates in unlimited mode. That=92s because rate_bps is zero in that = case. I could clean up that test by having a separate =93peeling = threshold=94 calculated at configure time. - Jonathan Morton