From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B2CB53B2A4 for ; Tue, 20 Aug 2019 14:31:51 -0400 (EDT) Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CB5B32A09AC for ; Tue, 20 Aug 2019 18:31:50 +0000 (UTC) Received: by mail-lj1-f199.google.com with SMTP id n2so1059152lji.13 for ; Tue, 20 Aug 2019 11:31:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=ucZ0kc/xALYACgRhsTNnCok6YOofAVVRJAVDWqV+E1Y=; b=gR0RG2uoHzVckx0kbCp6AXGPC0iVQ9B0MhH5iQKbHBJpWZpL83WnX5owW1fbQzaq0s lqHz+GTzSudxL2am+oa3FzJeP3RV5Y3DliNdCsWgmF5Gw4AKKxCfpwZITYn6Hq46X24z dFpx7fXtMopR9ilbGpcXsTGAXj+6+UBDbCzjOwHoQmE25t740LZ1wwr8ydkqr8zsQVZq WtwgtVE9zl0lSNGD1NcPLQY13+9puMqDQcku+z2tmnWkOwOpDzghyOE7d7wzYznk5LUC jDPbb0n0oC1wAiIHb4kpkdTEhwik/wmWSSX1hts9i320wxVakZBYGaZwYsUNTPfNLXrc eC5Q== X-Gm-Message-State: APjAAAVQcq1qSRyAcoJWIzoDWdZ6Tb1l54WuI63diOK/Eb5jfP5R98ex XrWZB4hml1ai7074V5GgJoMAEdyQHGGL76GJu98GcIBLZCzl2ZKi5pWDw5rTSF/nW0vTtPi2MvE NB9klYAMR95BqlEW1ZzatDg== X-Received: by 2002:a2e:804b:: with SMTP id p11mr2898147ljg.172.1566325909229; Tue, 20 Aug 2019 11:31:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqzN+2es6Cf00AuFC4DnZGqi0lxCBNPfmEy4bv3ssrSS2b1y4Bdqb86++feo97mt9pZf9a7p/g== X-Received: by 2002:a2e:804b:: with SMTP id p11mr2898136ljg.172.1566325908947; Tue, 20 Aug 2019 11:31:48 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id f23sm2888952lja.25.2019.08.20.11.31.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Aug 2019 11:31:48 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 2874F181CE4; Tue, 20 Aug 2019 20:31:47 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Sebastian Gottschall , Dave Taht Cc: "cake\@lists.bufferbloat.net \>\> Cake List" In-Reply-To: <74bccc2b-b805-255f-b6a7-83ade9af6765@newmedia-net.de> References: <384866b4-4c91-cf2c-c267-ee4036e5fbf7@newmedia-net.de> <87wof7sriw.fsf@toke.dk> <6782ec15-30eb-63b0-f54f-376c5e6b840b@newmedia-net.de> <87tvabsp99.fsf@toke.dk> <74bccc2b-b805-255f-b6a7-83ade9af6765@newmedia-net.de> X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 20 Aug 2019 20:31:47 +0200 Message-ID: <87r25fsn70.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Cake] cake in dd-wrt 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, 20 Aug 2019 18:31:51 -0000 Sebastian Gottschall writes: >>> we are already using filters. yes. its just that cake is acting always >>> as root and we have different sorts of qos configurations. so you have >>> wan. but we may have multiple lan interfaces with individual qos >>> settings. the same for mac / ip based user settings. so in fact we need >>> to create a individual qdisc for each of these setting types in worst >>> case, but in that case we cannot take in account the global available >>> bandwidth anymore. >> Ah, right, I see. So this is things like users wanting to limit a >> specific type of traffic to a certain bandwidth? > basicly yes. there are multiple ways. plain traffic shaping by local > interface name, by local mac, by local ip/net > and in addition there is shaping by port based or dpi based packet > detection and since each instance of cake doesnt know of any other > use of cake qdiscs its getting complicated. but we just started with > working on it. i'm sure i find a solution for it Do let us know if you do :) However, I'd also point out that when running CAKE a lot of these kinds of setups become simply redundant. For home networks most of the setups I have seen with such rule-based shaping is simply there to paper over the underlying bufferbloat issue. Once you solve that you don't really need all the policy-based stuff. Now, there are of course exceptions to this where a strict rule-based shaping *is* really needed; but HTB already provides this in the kernel, and we don't want to re-invent that, so I'm not sure we'll ever support this properly in CAKE, sadly... -Toke