From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5E6CB3B2A2 for ; Mon, 28 Mar 2016 08:09:40 -0400 (EDT) Received: from hms-beagle.lan ([93.237.70.232]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MDhGw-1aWlgq24Tu-00H64K; Mon, 28 Mar 2016 14:09:38 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <66A00804-E571-4A44-BE3E-422F78C1F1F7@gmail.com> Date: Mon, 28 Mar 2016 14:09:37 +0200 Cc: Allan Pinto , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <34953EAA-4C76-456E-9B9E-3A73D0DACCDE@gmail.com> <855E3354-30E6-4658-AF38-A0C1E92085CE@gmail.com> <66A00804-E571-4A44-BE3E-422F78C1F1F7@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:BQaXeq6MrQX5VMC1a1WaN7JOPY10oHSbZheb7wwwrdDQl2gAxpS eF2DB+kzCQsEM1IsdDezWwBhrzT6/IQ/HD23QEC/l3r5tMuG3uvwbqT8Z3ovZpxlsfgzAZm Arge233j6NbmozNAGnM2Q/olNCM5NfQ8F2Smvl+7m43U4IewYQMPxGKR4jH+2FPCaxAwG5I 2LJof79zzAEka6LzusPEA== X-UI-Out-Filterresults: notjunk:1;V01:K0:yXGhGXU533w=:CaTBuXQ9y5S2wNsg+LMG1G zt+QNkNkSdED3mUFb0L3DaRxr5pFHTq8WoRSeiVwF//qMYOjyunyrs6ESLGCOjJkYwLq13q0o mfO3vVmQ1dEYfdJY/QfDzlm/ULTUpAOmEfPJE3Moj9U5NN3HCjrtW3XbfKnj6ckmIC+i2KucL wSHSagAOCz4ttfnyNKCZfMvVf8DLBkFLkEdvdGHKAJ0IuOHZZQ6W6Udh6cteWpFVV/cRWAYCB WDGxOQThHIivHe6RksRJUOuXlqXANdXaHnqzeQukbv66DoSCeBEwbfXHKKUjKztPxuqN5y6a7 f83nQvp1P+3xb3I2wBkSLHyTlY333zyLEyV94xFeWmSD5Dkm5pJFOrPntYMFaND61jXIv50R1 OUoPk15IIhmVZAySoHLbevR3lNhBR8/ckKjkhuRxgQ+SEeIRmLQHFufGYcm8Joan5rPYdUyZV AwUu4WBf651bn58jrtRW2QPvKsCODo3zouNbx8TrSCtVawCjwsW0qbkWZY4wrsoDSM1KhnFP5 LisuWXx4n7Uf9ev8e6UPKPbYlzHspMOfYkDnJIN8hAns9CfbwSCE1W5+00Oesw1j9dOHuRUA8 dJhuYNrnu+Fns4dja4g4zZWe3tS1l+vQ8XwJI92Lv85+qpyYp3zMIb3iLY4pw/QKqAU6JBKC0 tSFvegFkgVSzep5V1gZTvEMGfI/zouICp95cfA0ARkMDoC0nffE5bQ8ubNovgdFdIyc2P3Gb9 beiUmnx+EYZMrTO2Wh/qQIShnmA11SJkGKxfQ82A94Qf8uYSqxOBRx4wwJZ9dIJZ/XPpYsP17 YsgKQ6i 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 12:09:40 -0000 Hi Jonathan, > On Mar 28, 2016, at 12:31 , Jonathan Morton = wrote: >=20 >=20 >> On 27 Mar, 2016, at 11:20, moeller0 wrote: >>=20 >> it might be more future-proof to just use IFBs from the get-go >=20 > 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. As I just wrote, can=E2=80=99t we completely avoid the IMQ/IFB = here and use dual egress shaping instead (once on the pppoe device and = once on the interface connected to the switch, which effectively should = shape both directions)? >=20 > However, I think this would work - though it=E2=80=99s completely = untested: >=20 > ip link set ifb0 up >=20 > tc qdisc replace dev ppp0 root handle 1: cake pppoe-vcmux bandwidth = $FULL_RATE triple-isolate I wonder how you came up with pppoe-vcmux, I have not seen any = information about the link technology in Allan=E2=80=99s post. As far as = I know a number of (mislead) ISPs use PPPoE even on fiber links. @Allan, = what is the link technology you use? >=20 > tc qdisc replace dev imq0 root handle 2: cake raw bandwidth = $NONCACHE_RATE flows I believe this might work as egress on the interface facing the = L2-switch=E2=80=A6 >=20 > tc filter replace dev ppp0 protocol ip prio 1 handle 11 u32 match ip = src $CACHE_IP/32 >=20 > tc filter replace dev ppp0 protocol ip prio 2 handle 12 u32 action = mirred egress redirect dev ifb0 >=20 > 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. >=20 > 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. =20 It should, but only on egress=E2=80=A6 > I=E2=80=99d appreciate feedback on whether this system does in fact = work. >=20 >> I would respectfully recommend to avoid the symbolic overhead = parameters >=20 > 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=99ve given for the current scheme. I mostly wanted to raise = awareness that the overhead compensation system exists for use on = encapsulated links. All fair points! >=20 > - Jonathan Morton >=20 Best Regards Sebastian=