Re: Problem with queuing vlan tagged packets after migration from 3.16.0 to 4.9.0

[Bartek Kois <bartek.kois@gmail.com>]

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.kois@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.