[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a322976c-6d47-aae8-32eb-3593f8e3cc10@gmail.com>
Date: Mon, 21 Sep 2020 12:44:43 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Nikolay Aleksandrov <nikolay@...dia.com>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
"olteanv@...il.com" <olteanv@...il.com>,
Roopa Prabhu <roopa@...dia.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"davem@...emloft.net" <davem@...emloft.net>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"andrew@...n.ch" <andrew@...n.ch>
Subject: Re: [PATCH net-next] net: bridge: pop vlan from skb if filtering is
disabled but it's a pvid
On 9/14/20 1:11 PM, Florian Fainelli wrote:
>> Less important, but still:
>> - it is in the fast path for everyone
>> - it can already be fixed by a tc action/8021q device
>
> Sure, but the point is that it should be fixed in a way that is
> transparent to the user, as much as possible.
>
>>
>> We can go into details but that would be a waste of time, instead I
>> think we
>> should focus on Vladimir's proposed DSA change.
>>
>> Vladimir, I think with the right pvid helper the patch would reduce to
>> dsa_untag_bridge_pvid() on the Rx path only. One thing that I'm
>> curious about
>> is shouldn't dsa_untag_bridge_pvid() check if the bridge pvid is == to
>> the skb
>> tag and the port's pvid?
>> Since we can have the port's pvid different from the bridge's. That's
>> for the
>> case of vlan_filtering=1 and the port having that vlan, but not as pvid.
Vladimir, let me know if you have a patch for DSA and I can give it a
try quickly. Thanks!
--
Florian
Powered by blists - more mailing lists