From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 187C5C43444 for ; Fri, 18 Jan 2019 04:56:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E2D8620883 for ; Fri, 18 Jan 2019 04:56:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727202AbfARE4S (ORCPT ); Thu, 17 Jan 2019 23:56:18 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:40920 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726902AbfARE4R (ORCPT ); Thu, 17 Jan 2019 23:56:17 -0500 X-Greylist: delayed 1377 seconds by postgrey-1.27 at vger.kernel.org; Thu, 17 Jan 2019 23:56:17 EST Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1gkLqK-0004sC-4Q; Thu, 17 Jan 2019 21:33:20 -0700 Received: from ip68-227-174-240.om.om.cox.net ([68.227.174.240] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1gkLqF-0007dA-8e; Thu, 17 Jan 2019 21:33:19 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Jamal Hadi Salim Cc: Cong Wang , Bartek Kois , Linux Kernel Network Developers References: <9f72e7e8-34a5-7bdb-7719-c4a5d35e9fd8@gmail.com> <0498cc65-fd90-034a-2a23-9b2fdc3ef3c0@gmail.com> <0ac07009-2add-a35c-d5b4-0b3f3b699d49@mojatatu.com> Date: Thu, 17 Jan 2019 22:32:46 -0600 In-Reply-To: <0ac07009-2add-a35c-d5b4-0b3f3b699d49@mojatatu.com> (Jamal Hadi Salim's message of "Sun, 6 Jan 2019 09:44:30 -0500") Message-ID: <87d0oushzl.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1gkLqF-0007dA-8e;;;mid=<87d0oushzl.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=68.227.174.240;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18vqpP4+KSa5xRgb+2NvGp472mGAZVru7I= X-SA-Exim-Connect-IP: 68.227.174.240 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: Problem with queuing vlan tagged packets after migration from 3.16.0 to 4.9.0 X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Jamal Hadi Salim 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 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