From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 68DCB21F431 for ; Mon, 16 Nov 2015 10:25:21 -0800 (PST) Received: by wmvv187 with SMTP id v187so190846459wmv.1 for ; Mon, 16 Nov 2015 10:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6eaRR/JpUZNnVxNpaLUI8sN4aQRtVOtv9ENN77CsI1Q=; b=vqlLshIEISn/Jgzkp37HDcA46COqz0ytxPlziWu9+gWO3U7zj9nFQNTynbUAmcx5mm vnGQM2e8T6MlHMGvqUC/AAQnAFexTKDNhDR17YE8Cpvyo9AuZgU3H70PjePv6g6FKhkv 3YY+vu1PpnOgmNrR1cy46VNf2DTLC/yDqIAq60FBbmsRCtY5YEVa822/aHiPhM0arcfM ZynOkcwFS7h7Mc0c58v1o5RoM7Lu5+D0idDX/UqIGnbJ8fjQbebYGV7f92Qjy0/58pPy 7QKtbdifmHuZWHALLW4UZ/SBAICMYdWvEkPQtL3OCglVj5EIDku1K+VMiG6W1E1VC50G tkbg== MIME-Version: 1.0 X-Received: by 10.28.87.21 with SMTP id l21mr21040703wmb.6.1447698320021; Mon, 16 Nov 2015 10:25:20 -0800 (PST) Received: by 10.194.42.168 with HTTP; Mon, 16 Nov 2015 10:25:19 -0800 (PST) In-Reply-To: <564A1C6D.3050303@darbyshire-bryant.me.uk> References: <56420697.9080606@darbyshire-bryant.me.uk> <5649EF39.3060300@darbyshire-bryant.me.uk> <5649F423.40000@darbyshire-bryant.me.uk> <564A169D.1060307@darbyshire-bryant.me.uk> <564A1C6D.3050303@darbyshire-bryant.me.uk> Date: Mon, 16 Nov 2015 19:25:19 +0100 Message-ID: From: Dave Taht To: Kevin Darbyshire-Bryant Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Announce - possible new feature - DSCP cleaning 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: Mon, 16 Nov 2015 18:25:44 -0000 I grok... short rate_overhead;// kind of stands out. s16 is the equivalent.... so the intent here is to have the rate flags get twiddled by userspace to enable squashing separately? one "feature" of squashing the old way was we did not need to allocate more than one tin... Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi On Mon, Nov 16, 2015 at 7:11 PM, Kevin Darbyshire-Bryant wrote: > tin_cnt *is* u16, in fact struct cake_sched_data has been restored to > the same state as it was before I introduced 'u8 squash'. > > On 16/11/15 17:59, Dave Taht wrote: >> yes and nooo..... I thought tin_cnt needed to be a 10 bit number at >> least.... (did it become an 8 bitter somewhere?) >> >> >> but I have not looked at the code in quite some time. Tomorrow I hope >> to finally have a fresh head. >> >> Right now I'm merely wrestling with getting a build to complete. >> Dave T=C3=A4ht >> Let's go make home routers and wifi faster! With better software! >> https://www.gofundme.com/savewifi >> >> >> On Mon, Nov 16, 2015 at 6:47 PM, Kevin Darbyshire-Bryant >> wrote: >>> Does this >>> https://github.com/dtaht/sch_cake/commit/d05cf7e003d9c13d8382c881655807= bda7ab3616 >>> improve your happiness factor? >>> >>> Kevin >>> >>> On 16/11/15 15:57, Dave Taht wrote: >>>> isn't there some other boolean variable somewhere ? >>>> >>>> Dave T=C3=A4ht >>>> Let's go make home routers and wifi faster! With better software! >>>> https://www.gofundme.com/savewifi >>>> >>>> >>>> On Mon, Nov 16, 2015 at 4:20 PM, Kevin Darbyshire-Bryant >>>> wrote: >>>>> On 16/11/15 15:03, Dave Taht wrote: >>>>>> I have not been doing any active development until... tomorrow. >>>>>> >>>>>> A goal I have for today is to actually build a version of openwrt + >>>>>> all this stuff for the linksys ac1200. >>>>>> >>>>>> I was not particularly huge on using another field (q->squash) to >>>>>> trigger squashing, and I cannot come up with a use case that makes >>>>>> sense to me. >>>>>> >>>>>> Under what circumstances do you think separating these two functions >>>>>> to be useful? >>>>> I wanted to be able to use diffserv marking for internal bandwidth >>>>> policing purposes whilst clearing those bits by the time they hit the >>>>> ISP. On ingress it makes no sense, on egress I can see a use. >>>>> >>>>> >>>>> >>> > >