From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DECD93B2A2 for ; Mon, 28 Mar 2016 06:36:16 -0400 (EDT) Received: by mail-oi0-x229.google.com with SMTP id r187so166222956oih.3 for ; Mon, 28 Mar 2016 03:36:16 -0700 (PDT) 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; bh=Z4WXW/CS9kfUIqjX0WUGS9ubCHdhPxlK3KZUIiZMVQ4=; b=vJ+rfk6Uf9Btnp3CqpOEBJJroY64/RHm96Q1xWb7OQT494M1xprZt7IuOAUwgpxlgE Od9V4HzWjT66GJZKsIYg1c2pY162Zjimm5mQkM6fbpEFlDml8ItuVm0xrAFKbQi+gQuE 57TmfrsMl8YYLJQW4daVPIfjYu+S2z1/clNaI8SNM+Nrc2E1+reqteJeZv9iXMeYauUq TZQCPKW76re9J/qV+9IsoyxfDO6OgS65RR/PACRvk1fQyTblxwwsYhchmtAqgjx7n+Vq mG9lGKyJ94ZIQbms1e5XrUsKbtA5UBDBHyv0eufVhjMS1L49/CtjFVI6I7I8m1+s7Eus Hddg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Z4WXW/CS9kfUIqjX0WUGS9ubCHdhPxlK3KZUIiZMVQ4=; b=gvjGN7tpq5u40Q3LW33FxYwmmir0WuXtDQGIZFGcd7p3AlZRJgxocqOapiIqUqDr8t lsYGD9PIXPkuLVXDkbTbX2txPxmLdvP+GSVkArYHwV3dcx3cJmlU6lrk3FejWWawG4KD RD+L5BBdM1Ecn9vnsFaCGVZ7Td+5pELiYwqGCiEhSXrOic4azIfgZLEBN9GJliCb60P0 NIbr8ZwymVPxJ+zFkKCPvJo6ThwY69vuuRJQ8K9Pg2HO3KioEdeJir6HNAWy8ImxwTVc iyIapUVVFKhrCmw/rz//wA5q4M9J9fJVb4hMZWKn5LEOHWO602kqqekXFXebL5GfS861 a7Ig== X-Gm-Message-State: AD7BkJL4A1cV5gMhXE3KRoKOfr9X2VGav2HdHtfWwScENldaSp53MWBsewQSHa3+2ggRdQHqA0UrJKuYu5mbZg== MIME-Version: 1.0 X-Received: by 10.157.46.42 with SMTP id q39mr1062195otb.136.1459161376038; Mon, 28 Mar 2016 03:36:16 -0700 (PDT) Received: by 10.202.89.130 with HTTP; Mon, 28 Mar 2016 03:36:15 -0700 (PDT) In-Reply-To: <66A00804-E571-4A44-BE3E-422F78C1F1F7@gmail.com> References: <34953EAA-4C76-456E-9B9E-3A73D0DACCDE@gmail.com> <855E3354-30E6-4658-AF38-A0C1E92085CE@gmail.com> <66A00804-E571-4A44-BE3E-422F78C1F1F7@gmail.com> Date: Mon, 28 Mar 2016 16:06:15 +0530 Message-ID: From: Allan Pinto To: Jonathan Morton Cc: moeller0 , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a113dbf047d23ca052f197bd1 Subject: Re: [Cake] cake separate qos for lan 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, 28 Mar 2016 10:36:17 -0000 --001a113dbf047d23ca052f197bd1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >tc qdisc replace dev imq0 root handle 2: cake raw bandwidth $NONCACHE_RATE flows here imq0 should be replaced by ifb0 right?. i will be testing this tonight and reply with results. On Mon, Mar 28, 2016 at 4:01 PM, Jonathan Morton wrote: > > > On 27 Mar, 2016, at 11:20, moeller0 wrote: > > > > it might be more future-proof to just use IFBs from the get-go > > For this particular use-case, it seems to be more complicated to use IFB > than IMQ, largely because there is no iptables rule to divert packets > through an IFB device, and unlike iptables, the CBQ filter mechanism > doesn=E2=80=99t directly support negative matches of any kind. > > However, I think this would work - though it=E2=80=99s completely unteste= d: > > ip link set ifb0 up > > tc qdisc replace dev ppp0 root handle 1: cake pppoe-vcmux bandwidth > $FULL_RATE triple-isolate > > tc qdisc replace dev imq0 root handle 2: cake raw bandwidth $NONCACHE_RAT= E > flows > > tc filter replace dev ppp0 protocol ip prio 1 handle 11 u32 match ip src > $CACHE_IP/32 > > tc filter replace dev ppp0 protocol ip prio 2 handle 12 u32 action mirred > egress redirect dev ifb0 > > The logic of the above is that a positive match is made on the cache > traffic, but no action is taken. This terminates filter processing for > that traffic. The remaining traffic is redirected unconditionally to the > IFB device by the second filter rule. > > One thing I=E2=80=99m not entirely certain of is whether traffic that has= been > through an IFB device is then requeued in the normal way on the original > device. I=E2=80=99d appreciate feedback on whether this system does in f= act work. > > > I would respectfully recommend to avoid the symbolic overhead parameter= s > > Even if I change their underlying behaviour in the future, it=E2=80=99ll = be in a > way that retains backwards compatibility with all the examples I=E2=80=99= ve given > for the current scheme. I mostly wanted to raise awareness that the > overhead compensation system exists for use on encapsulated links. > > - Jonathan Morton > > --=20 Thanx and regd's. Allan. --001a113dbf047d23ca052f197bd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>tc= qdisc replace dev imq0 root handle 2: cake raw bandwidth $NONCACHE_RATE fl= ows
here imq= 0 should be replaced by ifb0 right?.
i will be testing this tonight and reply wit= h results.

On Mon, Mar 28, 2016 at 4:01 PM, Jonathan Morton <chromati= x99@gmail.com> wrote:

> On 27 Mar, 2016, at 11:20, moeller0 <moeller0@gmx.de> wrote:
>
> it might be more future-proof to just use IFBs from the get-go

For this particular use-case, it seems to be more complicated to use= IFB than IMQ, largely because there is no iptables rule to divert packets = through an IFB device, and unlike iptables, the CBQ filter mechanism doesn= =E2=80=99t directly support negative matches of any kind.

However, I think this would work - though it=E2=80=99s completely untested:=

ip link set ifb0 up

tc qdisc replace dev ppp0 root handle 1: cake pppoe-vcmux bandwidth $FULL_R= ATE triple-isolate

tc qdisc replace dev imq0 root handle 2: cake raw b= andwidth $NONCACHE_RATE flows

tc filter replace dev ppp0 protocol ip prio 1 handle 11 u32 match ip= src $CACHE_IP/32

tc filter replace dev ppp0 protocol ip prio 2 handle 12 u32 action mirred e= gress redirect dev ifb0

The logic of the above is that a positive match is made on the cache traffi= c, but no action is taken.=C2=A0 This terminates filter processing for that= traffic.=C2=A0 The remaining traffic is redirected unconditionally to the = IFB device by the second filter rule.

One thing I=E2=80=99m not entirely certain of is whether traffic that has b= een through an IFB device is then requeued in the normal way on the origina= l device.=C2=A0 I=E2=80=99d appreciate feedback on whether this system does= in fact work.

> I would respectfully recommend to avoid the symbolic overhead paramete= rs

Even if I change their underlying behaviour in the future, it=E2=80= =99ll be in a way that retains backwards compatibility with all the example= s I=E2=80=99ve given for the current scheme.=C2=A0 I mostly wanted to raise= awareness that the overhead compensation system exists for use on encapsul= ated links.

=C2=A0- Jonathan Morton




--
Thanx and regd's.
=
Allan.

--001a113dbf047d23ca052f197bd1--