You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
7b4877c204
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 benefits:
- 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->hash from
before the encapsulation, which allows flow-based qdiscs to distinguish
between flows even though the outer packet header no longer has flow
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 part 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_hash is
set)
AND
- NAT header rewriting is either disabled, or did not change any values
used for hashing. The latter is important to match local-origin packets
such as those of a tunnel endpoint.
The immediate motivation for fixing this was the recent patch to WireGuard
to preserve the skb->hash on encapsulation. As such, this is also what I
tested against; with this patch, added latency under load for competing
flows drops from ~8 ms to sub-1ms on an RRUL test over a WireGuard tunnel
going through a virtual link shaped to 1Gbps using sch_cake. This matches
the results we saw with a similar setup using sch_fq_codel when testing the
WireGuard patch.
Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc")
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
|
4 years ago | |
|---|---|---|
| .github | 6 years ago | |
| config | 4 years ago | |
| include | 4 years ago | |
| package | 4 years ago | |
| scripts | 4 years ago | |
| target | 4 years ago | |
| toolchain | 4 years ago | |
| tools | 4 years ago | |
| .gitattributes | 12 years ago | |
| .gitignore | 4 years ago | |
| BSDmakefile | 17 years ago | |
| Config.in | 7 years ago | |
| LICENSE | 8 years ago | |
| Makefile | 4 years ago | |
| README | 5 years ago | |
| feeds.conf.default | 6 years ago | |
| rules.mk | 5 years ago | |
README
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
This is the buildsystem for the OpenWrt Linux distribution.
To build your own firmware you need a Linux, BSD or MacOSX system (case
sensitive filesystem required). Cygwin is unsupported because of the lack
of a case sensitive file system.
You need gcc, binutils, bzip2, flex, python3.5+, perl, make, find, grep, diff,
unzip, gawk, getopt, subversion, libz-dev and libc headers installed.
1. Run "./scripts/feeds update -a" to obtain all the latest package definitions
defined in feeds.conf / feeds.conf.default
2. Run "./scripts/feeds install -a" to install symlinks for all obtained
packages into package/feeds/
3. Run "make menuconfig" to select your preferred configuration for the
toolchain, target system & firmware packages.
4. Run "make" to build your firmware. This will download all sources, build
the cross-compile toolchain and then cross-compile the Linux kernel & all
chosen applications for your target system.
Sunshine!
Your OpenWrt Community
http://www.openwrt.org