From: ebiederm@xmission•com (Eric W. Biederman)
To: Jamal Hadi Salim <jhs@mojatatu•com>
Cc: Cong Wang <xiyou.wangcong@gmail•com>,
Bartek Kois <bartek.kois@gmail•com>,
Linux Kernel Network Developers <netdev@vger•kernel.org>
Subject: Re: Problem with queuing vlan tagged packets after migration from 3.16.0 to 4.9.0
Date: Thu, 17 Jan 2019 22:32:46 -0600 [thread overview]
Message-ID: <87d0oushzl.fsf@xmission.com> (raw)
In-Reply-To: <0ac07009-2add-a35c-d5b4-0b3f3b699d49@mojatatu.com> (Jamal Hadi Salim's message of "Sun, 6 Jan 2019 09:44:30 -0500")
Jamal Hadi Salim <jhs@mojatatu•com> writes:
> On 2019-01-05 12:03 a.m., Cong Wang wrote:
>> (Cc'ing Jamal)
>>
>> On Fri, Jan 4, 2019 at 10:11 AM Bartek Kois <bartek.kois@gmail•com> wrote:
>>>
>>> Basically my current scenario looks like this:
>>> - router with eth0 as WAN and eth1 as LAN with 10-20 vlans,
>>> - around 1000-2000 ip addresses in differnets subnets behind router (on
>>> the LAN side),
>>> - QoS made with tc + ifb (for upload queuing) + hasing filters (for
>>> performance reasons)
>>>
>>> Moving this to two queuing trees (one on vlan and one on ifbx) per each
>>> vlan makes this really hard to configure, but not impossible as long as
>>> I can redirect single VLAN to ifb (don`t know if that is possible).
>>> Anton suggested to use iptables+ipset but I don`t think that would be a
>>> good idea to do that in scenario with so many queues.
>>
>> Yeah, understood.
>>
>
> Classifying vlans via u32 has been broken for some time (4 years or
> more?). Some change made on general vlan handling (I think patch was
> from Jiri). So someone like Bartek would be in for a suprise
> if hasnt upgraded since.
Definitely more than 4. I was trying to sort pieces of this out maybe 6
years ago. For a while vlan tags on software devices worked one way and
vlan tags on actual hardware work the way vlan tags work for everything
now.
Since every option involved breaking something we standardized on the
way hardware accelleration handled vlan tags. Which caused some hiccups
on pure software devices. That ``fix'' may have gone in after 3.16 and
be why Bartek is seeing issues. Especially if his router had a very
lame ethernet device that did not support any hardware accelleration.
> vlan info is part of the skb metadata now and not visible
> in the packet data. To extract it youd have to use the inlines
> in include/linux/if_vlan.h(skb_vlan_tag_get() and friends)
Yes, and like you suggest down thread that will now require
a magic directive to read. The upside is if you don't care about
the vlan tag your offsets are likely to be more constant now.
Eric
next prev parent reply other threads:[~2019-01-18 4:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-29 12:52 Problem with queuing vlan tagged packets after migration from 3.16.0 to 4.9.0 Bartek Kois
2018-12-30 18:53 ` Cong Wang
2018-12-30 21:14 ` Bartek Kois
2018-12-31 18:13 ` Bartek Kois
2019-01-01 19:33 ` Cong Wang
2019-01-01 19:46 ` Bartek Kois
2019-01-03 3:30 ` Cong Wang
2019-01-03 15:25 ` Bartek Kois
2019-01-03 20:44 ` Cong Wang
2019-01-04 18:11 ` Bartek Kois
2019-01-05 5:03 ` Cong Wang
2019-01-06 14:44 ` Jamal Hadi Salim
2019-01-10 13:45 ` Simon Horman
2019-01-12 12:12 ` Jamal Hadi Salim
2019-01-13 18:22 ` Cong Wang
2019-01-15 15:09 ` Jamal Hadi Salim
2019-01-15 18:19 ` Cong Wang
2019-01-16 14:13 ` Jamal Hadi Salim
2019-01-14 8:12 ` Simon Horman
2019-01-15 15:16 ` Jamal Hadi Salim
2019-01-18 4:32 ` Eric W. Biederman [this message]
2019-01-03 21:49 ` Anton Danilov
2019-01-04 7:07 ` Bartek Kois
2018-12-31 21:47 ` Jakub Kicinski
2018-12-31 22:12 ` Bartek Kois
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d0oushzl.fsf@xmission.com \
--to=ebiederm@xmission$(echo .)com \
--cc=bartek.kois@gmail$(echo .)com \
--cc=jhs@mojatatu$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=xiyou.wangcong@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox