From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E71F73BA8E for ; Tue, 21 Aug 2018 17:17:14 -0400 (EDT) Date: Tue, 21 Aug 2018 23:17:12 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1534886233; bh=Y7pcERtImgEOQAiBkmL96d9pr8VH9KsfsgzK3cRjEms=; h=Date:In-Reply-To:References:Subject:To:CC:From:From; b=NHiFJQ/IKSlhmv6HdChmsLPUNw3KVw6kMatNCk2Jn+ZWaKG14Du1xV/vRPwm53hmQ PLN+UFPe9ctaCN5Oai3COdGe8GCUZS4sijHa808Hc4krbv6eWUuw1RF6V6IerLjopg roX3sohSWVqmwY/wHuuRQyVx/tNoPH64akfMXCiZGTBURzoNfmCCwEvKocmgNjmBbf 8vXvW60rsERtQOR1OGKyKbv0etUrKUNSP1cQ02vhG/CgTSPYPYj8fXgoPfnTpTZw88 MRvY4ICurgrcm+1r6Qg6LlL+ScMtyRB+DFKIx3atR2u9quIk4XiLigT6hv101fSRX7 d9c7aRO90Tjcw== In-Reply-To: References: <87h8jze5hk.fsf@toke.dk> <85C60B2F-78D0-4AEE-871C-BB637785BF62@gmail.com> <4D28C453-5378-4A5B-9E05-874F36C4DB30@gmail.com> <878t5aedj5.fsf@toke.dk> <87d0uc9d2f.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Pete Heist CC: Jonathan Morton , Cake List From: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <2689078D-1548-49E7-A9BC-B39980002278@toke.dk> 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: Tue, 21 Aug 2018 21:17:15 -0000 On 21 August 2018 23:06:11 CEST, Pete Heist wrote: > >> On Aug 21, 2018, at 1:25 PM, Toke H=C3=B8iland-J=C3=B8rgensen >wrote: >>=20 >>>> The next simplest fix is to ignore the flow ID override unless >we're >>>> in "flows" mode=2E We can then make valid assumptions about what >should >>>> go into the host tables=2E >>>>=20 >>>> 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)=2E 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"=2E >>>=20 >>> 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=2E I'll see if I can't integrate this=2E >>=20 >> So, I implemented this; in the latest commit on github it is again >> possible to override the flow hashing by setting the class ID with a >TC >> filter; and the host hash can be overridden by setting the major >number >> of the class ID=2E In my testing the hangs from before are gone, but if >> anyone else wants to test, please do! >>=20 >> I'll write up a description of the filter overrides in the man page, >and >> submit the change upstream as well=2E=2E=2E > > >Well that=E2=80=99s good timing for me as I=E2=80=99m wrapping up a small= utility/eBPF >to classify an arbitrary username to either MAC or IP=2E Here=E2=80=99s t= he work >in progress, which is not done yet as flow fairness is still under >construction, and I haven=E2=80=99t gotten my IPv6 support to pass the ra= ther >stubborn eBPF verifier: https://github=2Ecom/heistp/tc-users > Did you see my classifier? Does subnet-to-flow mapping=2E https://github= =2Ecom/tohojo/tc-classifier Feel free to reuse it in whole or in part=2E=2E=2E >With your new code Toke: >- I so far haven=E2=80=99t seen my VM either crash or suddenly fill its d= isk >with logs, which is a bonus=2E :) Awesome! >- With the new major/minor ID distinction, I=E2=80=99d probably use major= for >the user and minor for the flow hash? Yes=2E See the latest commit in the tc-adv repo for a man page update expl= aining it=2E You can also just set the major ID and let cake do the flow ha= shing=2E=2E=2E >Another thing I haven=E2=80=99t looked into yet is that when fq_codel is = the >qdisc, the eBPF action is only called "once in a while=E2=80=9D (start of= a new >flow?) With cake it=E2=80=99s called for every single packet, which is wh= at I >expected to happen, but very different behavior=2E Maybe because fq_codel is not splitting gso packets? >Lastly, if anyone has time to review even just a little code for what >is or is not good or idiomatic C, post an issue and I=E2=80=99d appreciat= e it=2E >Yes, I yield to the =E2=80=98goto=E2=80=99 proponents when it comes to er= ror handling >and resource de-allocation=2E :) I'll take a look tomorrow :) -Toke