Hi
1. What exactly caused this change in the kernel?
2. I don`t understand why adding VLAN tag, which is just 4 additional
bytes to the passing packet make it impossible to classify.
3. This whole thing makes the QoS under Linux routers hard to configure
in scenarios with more than one VLAN which is pretty much every slightly
bigger router nowadays especially if we use IFB and hashing filters. Is
there any walkaround for that problem?
Best regards
Bartek Kois
W dniu 03.01.2019 o 04:30, Cong Wang pisze:
On Tue, Jan 1, 2019 at 11:46 AM Bartek Kois <bartek.k...@gmail.com> wrote:
Hi
Yes it did work since I remember (like around 2.4.x) and it changed
since I moved from Debian 8 to 9. I would appreciate fixing that in the
future beacuse it is essential for queueing traffic on the routers, but
the question is why these filters don`t work in that case:
tc filter add dev $LAN_ETH parent 1:0 protocol ip prio 4 u32 match
u32 0x0a000c08 0xffffffff at 20 classid 1:2001 # for 10.0.12.8 ip
address
tc filter add dev $LAN_ETH parent 1:0 protocol ip prio 4 u32 match
u32 0x0a000c09 0xffffffff at 20 classid 1:2002 # for 10.0.12.9 ip
address
tc filter add dev $LAN_ETH parent 1:0 protocol ip prio 4 u32 match
u32 0x0a000c10 0xffffffff at 20 classid 1:2003 # for 10.0.12.10 ip
address
I`ve changed "at 16" which works without vlan tags to "at 20" to take
vlan tag into account.
Yeah, this confirms my speculation.
The problem is essentially a design flaw of u32 filter, the IP header
and TCP header offsets are never fixed, for example VLAN tagging and
IP options. What's more, it is not easy for user-space to learn the offset
for different packets as it requires to parse into each packets.
I don't know whether we can fix this either, VLAN call path probably
already makes assumptions on the current skb->data position, if
we "fix" it for u32, it would probably break other things.
