From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dave@taht.net>
Received: from mail.taht.net (mail.taht.net [176.58.107.8])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by lists.bufferbloat.net (Postfix) with ESMTPS id B0F933B29E
 for <cerowrt-devel@lists.bufferbloat.net>;
 Sat, 19 Jan 2019 09:47:54 -0500 (EST)
Received: from dancer.taht.net (unknown
 [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.taht.net (Postfix) with ESMTPSA id 9FDA6221D8
 for <cerowrt-devel@lists.bufferbloat.net>;
 Sat, 19 Jan 2019 14:47:53 +0000 (UTC)
From: Dave Taht <dave@taht.net>
To: cerowrt-devel@lists.bufferbloat.net
References: <9f72e7e8-34a5-7bdb-7719-c4a5d35e9fd8@gmail.com>
 <CAM_iQpUnXGM45=w6ts2DEDX3+eS46FDtG95CCy07R0Fa0pmcaw@mail.gmail.com>
 <de2e92c4-3b4b-3b0a-2f5c-e91da15e08a3@gmail.com>
 <a8cb8964-07b0-ef21-5565-9fe76ecf1f9c@gmail.com>
 <CAM_iQpWbx5MweaA5bnsL6ZrC2DFsdEGZ4uXhQa1AxM+bR4qHuQ@mail.gmail.com>
 <d9cbb909-6514-138f-74dc-bb82cdbaa4b9@gmail.com>
 <CAM_iQpU332Vrv5bZ10TYJ-crRUR0Y2yzgY41+eChs3hGJQzaoA@mail.gmail.com>
Date: Sat, 19 Jan 2019 06:47:13 -0800
In-Reply-To: <CAM_iQpU332Vrv5bZ10TYJ-crRUR0Y2yzgY41+eChs3hGJQzaoA@mail.gmail.com>
 (Cong Wang's message of "Wed, 2 Jan 2019 19:30:53 -0800")
Message-ID: <87bm4cogb2.fsf@taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Cerowrt-devel] Problem with queuing vlan tagged packets after
	migration from 3.16.0 to 4.9.0
X-BeenThere: cerowrt-devel@lists.bufferbloat.net
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Development issues regarding the cerowrt test router project
 <cerowrt-devel.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/cerowrt-devel>,
 <mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/cerowrt-devel>
List-Post: <mailto:cerowrt-devel@lists.bufferbloat.net>
List-Help: <mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/cerowrt-devel>,
 <mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Sat, 19 Jan 2019 14:47:54 -0000


Perhaps this has been a source of some subtle bugs in sqm?

Cong Wang <xiyou.wangcong@gmail.com> writes:

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