From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DD7913B29D for ; Sun, 31 May 2020 00:52:45 -0400 (EDT) Received: from localhost (unknown [IPv6:2601:601:9f00:477::3d5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 678A3128FE1E8; Sat, 30 May 2020 21:52:44 -0700 (PDT) Date: Sat, 30 May 2020 21:52:43 -0700 (PDT) Message-Id: <20200530.215243.413220351888088239.davem@davemloft.net> To: toke@redhat.com Cc: netdev@vger.kernel.org, cake@lists.bufferbloat.net From: David Miller In-Reply-To: <20200529124344.355785-1-toke@redhat.com> References: <20200529124344.355785-1-toke@redhat.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Sat, 30 May 2020 21:52:44 -0700 (PDT) Subject: Re: [Cake] [PATCH net] sch_cake: Take advantage of skb->hash where appropriate 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: Sun, 31 May 2020 04:52:46 -0000 From: Toke H=F8iland-J=F8rgensen Date: Fri, 29 May 2020 14:43:44 +0200 > While the other fq-based qdiscs take advantage of skb->hash and doesn= 't > recompute it if it is already set, sch_cake does not. > = > This was a deliberate choice because sch_cake hashes various parts of= the > packet header to support its advanced flow isolation modes. However, > foregoing the use of skb->hash entirely loses a few important benefit= s: > = > - When skb->hash is set by hardware, a few CPU cycles can be saved by= not > hashing again in software. > = > - Tunnel encapsulations will generally preserve the value of skb->has= h from > before the encapsulation, which allows flow-based qdiscs to disting= uish > between flows even though the outer packet header no longer has flo= w > information. > = > It turns out that we can preserve these desirable properties in many = cases, > while still supporting the advanced flow isolation properties of sch_= cake. > This patch does so by reusing the skb->hash value as the flow_hash pa= rt of > the hashing procedure in cake_hash() only in the following conditions= : > = > - If the skb->hash is marked as covering the flow headers (skb->l4_ha= sh is > set) > = > AND > = > - NAT header rewriting is either disabled, or did not change any valu= es > used for hashing. The latter is important to match local-origin pac= kets > such as those of a tunnel endpoint. > = > The immediate motivation for fixing this was the recent patch to Wire= Guard > to preserve the skb->hash on encapsulation. As such, this is also wha= t I > tested against; with this patch, added latency under load for competi= ng > flows drops from ~8 ms to sub-1ms on an RRUL test over a WireGuard tu= nnel > going through a virtual link shaped to 1Gbps using sch_cake. This mat= ches > the results we saw with a similar setup using sch_fq_codel when testi= ng the > WireGuard patch. > = > Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (c= ake) qdisc") > Signed-off-by: Toke H=F8iland-J=F8rgensen Applied to net-next, thanks.