On 11/26/20 6:51 PM, Daniel Lakeland wrote:
Strangely I can't seem to make a rule that sets the tc class work,
unless it's setting the class of the root qdisc?
....
What is going wrong?
Well, from testing, if I were to guess what's really going on it's that
"meta priority set" sets the packet's "priority" field using the
**minor** number only, and doesn't really do anything with the major number.
The kernel then always just hands the packet to the top level qdisc, and
it tries to interpret the minor number given in the priority field...
but if that minor number doesn't exist, then it either drops the packet
or uses its default depending on the qdisc.
To make this work, it's extremely useful to **not** reuse minor numbers
when creating sub-qdiscs and add some tc filters at the root for example:
tc filter add dev eno1 parent 1: protocol all basic match "meta(priority
eq 33)" flowid 2:33
I also found that of course my nftables doesn't have any arp tables or
do anything with packets not ipv4 or ipv6 so when I'm using a qfq qdisc
which has no default it was useful to have:
tc filter add dev eno1 parent 1: protocol all basic match "not
(meta(priority eq 1) or meta(priority eq 2) or meta(priority eq 3))"
flowid 1:4
or some such thing, which basically catches packets that don't have any
priority and sends them to a default. As soon as I did this my ipv4
started working again (ARP packets were being dropped).
Hope this helps some people, and please let me know if I've got it
wrong. this is all deduced from empirical testing.
