From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x242.google.com (mail-lb0-x242.google.com [IPv6:2a00:1450:4010:c04::242]) (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 2C26D3B2A0 for ; Mon, 28 Mar 2016 06:31:35 -0400 (EDT) Received: by mail-lb0-x242.google.com with SMTP id q4so1334431lbq.3 for ; Mon, 28 Mar 2016 03:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2l8kvBQBz8mWnfSPx2bHAhksPEJxrgp+eGwCGcAREdM=; b=ipK+4xTs9VAx/m/266W0Xukm/dpnr55tdDAS5Y/vlY72TqxCcjsVFB1nYecP5YRp5P td/LgG5uQKZtP4iHNGe/5fDY5IHqQplM2KuH9DkLJ5lOP2h2CNQZhbS+KBRie7RJcn+s jORJE2O4ZDcpCQoXVBOqFDzJSLCtZUpNQR+R4hcRMasVEH2agrL5K91OgPwBwn0ZAbo3 Xgqo3fuZB0gewyb2PYou3Vy0UOP2mXHwP/wImf9/l+LGOIjB8DMwZTcSB6vBPg48uHLK 9Ylvjc+CRTm/VJPlr4BwPuw7DHJGelDqg8Dz64QAHnLzRNGyvQZOEmrwiqQeNR+BEz/W Lq5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2l8kvBQBz8mWnfSPx2bHAhksPEJxrgp+eGwCGcAREdM=; b=FXsxAqJB0dw1WmhDKuF3XSHCjoQtGgNvV4AwpD5micyUEUm5HNvAu69n5dxedYeCI7 2bDZGbv+SPU4io2xdqr1GzuOy2JfvBweOhmBaoS1bvdjb3Mom4fOxOpda+KRtMVar5dq afvIFVMn7uHR3J97KABb2wGQ9G9c7YH1BnCvVecCwHM5xmeRuLeAFIonPSEFxt5juPQV nGPQcBvJuL5qqGXDVYEiGXLRX1Q1DwGVLUu+vrG6b6beb4+6r8g1HjtMMEsTUHrUGyTN zSBmbevvxyIR25j/GqiFD/tLLMSzbfqusu30DRxPVHOUZ12kFlzNdrqxm/jeapo2x4gN NCJA== X-Gm-Message-State: AD7BkJKFKMOZhTVAmkBafTVXsD5YQe7Angdt4aL0A/zGRul6CrZ9+s0YFdYBZkaOkFSAKg== X-Received: by 10.112.128.225 with SMTP id nr1mr9695253lbb.101.1459161093930; Mon, 28 Mar 2016 03:31:33 -0700 (PDT) Received: from bass.home.chromatix.fi (37-33-67-252.bb.dnainternet.fi. [37.33.67.252]) by smtp.gmail.com with ESMTPSA id qh4sm4294915lbb.43.2016.03.28.03.31.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 03:31:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Jonathan Morton In-Reply-To: Date: Mon, 28 Mar 2016 13:31:30 +0300 Cc: Allan Pinto , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <66A00804-E571-4A44-BE3E-422F78C1F1F7@gmail.com> References: <34953EAA-4C76-456E-9B9E-3A73D0DACCDE@gmail.com> <855E3354-30E6-4658-AF38-A0C1E92085CE@gmail.com> To: moeller0 X-Mailer: Apple Mail (2.3112) 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:31:35 -0000 > On 27 Mar, 2016, at 11:20, moeller0 wrote: >=20 > 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_RATE triple-isolate tc qdisc replace dev imq0 root handle 2: cake raw bandwidth = $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 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 fact work. > I would respectfully recommend to avoid the symbolic overhead = parameters 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. - Jonathan Morton