From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E2D4F3B2A4 for ; Mon, 13 Aug 2018 07:01:19 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1534158076; bh=lv+t9WejPFZfkiq4G0lVRcJixFD+bfYc6t/9xvLNZBI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ceSF0c+h9aASzjXXOZUCGavigbox2vwB8VH4cKZ5qrp5xJgXZHGZXxL/lIKfwv5qr iBFPb82iBE0TiVT9+ugO7ruMaF3JPk2s1cozL87F6KMJr252BmTvgQZwbDfHgg7hZY FXyYIXZttrvXG3m0b4+Sk4rpYgAmzaPVxJcWYJrnRmsaNgCVc/ErEDYEGo835iHxcj i4R/xGXJekd+Jah6/uGpXLUY1VOC0ukP9rcmjTrQORe1XWGNYvse7i9+pGCVEQMBJd 2HlgjYy5sFG2FOCA7DK7/MofSmqyJqBx8vqkda0SAuCJVk6eD2FOY/1gDVKlIP8cPo oZWs66Bx9N1oQ== To: Jonathan Morton Cc: Pete Heist , Cake List In-Reply-To: <4D28C453-5378-4A5B-9E05-874F36C4DB30@gmail.com> References: <87h8jze5hk.fsf@toke.dk> <85C60B2F-78D0-4AEE-871C-BB637785BF62@gmail.com> <4D28C453-5378-4A5B-9E05-874F36C4DB30@gmail.com> Date: Mon, 13 Aug 2018 13:01:18 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <878t5aedj5.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] issue with Cake and bpf filter X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 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, 13 Aug 2018 11:01:20 -0000 Jonathan Morton writes: >> On 13 Aug, 2018, at 12:34 am, Jonathan Morton wr= ote: >>=20 >>> On 12 Aug, 2018, at 10:42 pm, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>>=20 >>> Yes it does; setting tc_classid is one way to set the flow class that is >>> read by the call to tcf_classify(). I guess the problem is that >>> cake_hash() is bypassed, so the *host_refcnt variables are not >>> incremented. >>>=20 >>> There's been another report of the same issue on github; haven't had >>> time to look into it yet, but I guess this is the reason... >>=20 >> I'll see what I can do tonight, now that I understand the problem. > > Oh, this is a mess. Ultimately the problem stems from having > previously factored out choosing tin and flow to two distinct > functions, but now there's an external mechanism for overriding both > at once, which can only hook into one or the other. > > The easiest fix is to just remove the broken support for setting the > flow ID via a filter, but leave in the support for setting the tin. I > think that's the most useful "simple" fix. It's perhaps worth noting > that this was the first thing I *removed* when reworking fq_codel into > the first version of Cake, because I couldn't see a valid use for it. Well, seeing as lots of people have expressed interest in the feature since we put it back in it seems that there *is* a use for it :) > The next simplest fix is to ignore the flow ID override unless we're > in "flows" mode. We can then make valid assumptions about what should > go into the host tables. > > The *right* fix, if we want to maximise functionality, would be to > pass the result struct by reference into cake_hash(), where it can > override the *host* IDs (not the flow ID). Users can then choose > between using the override as a flow ID (by setting "hosts" mode > instead of "flows"), or retaining the default host-isolation semantics > with a revised definition of "host". Ah, making it possible to override both host and flow mode is a great idea! I guess we could use the major/minor distinction in the class to steer this. I'll see if I can't integrate this. > I feel compelled to point out that baggage like this is probably at > least some of why Cake is no longer faster than HTB+fq_codel, as it > used to be. The benchmarks showing HTB to be faster were performed before the classification went in, so I very much doubt that :) -Toke