| Message ID | 20200930203103.225677-1-f.fainelli@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [net-next] net: dsa: Support bridge 802.1Q while untagging | expand |
On Wed, Sep 30, 2020 at 01:31:03PM -0700, Florian Fainelli wrote: > While we are it, call __vlan_find_dev_deep_rcu() which makes use the > VLAN group array which is faster. Not just "while at it", but I do wonder whether it isn't, in fact, called "deep" for a reason: /* * Lower devices of master uppers (bonding, team) do not have * grp assigned to themselves. Grp is assigned to upper device * instead. */ I haven't tested this, but I wonder if you could actually call __vlan_find_dev_deep_rcu() on the switch port interface and it would cover both this and the bridge having an 8021q upper automatically?
On 9/30/2020 1:43 PM, Vladimir Oltean wrote: > On Wed, Sep 30, 2020 at 01:31:03PM -0700, Florian Fainelli wrote: >> While we are it, call __vlan_find_dev_deep_rcu() which makes use the >> VLAN group array which is faster. > > Not just "while at it", but I do wonder whether it isn't, in fact, > called "deep" for a reason: > > /* > * Lower devices of master uppers (bonding, team) do not have > * grp assigned to themselves. Grp is assigned to upper device > * instead. > */ > > I haven't tested this, but I wonder if you could actually call > __vlan_find_dev_deep_rcu() on the switch port interface and it would > cover both this and the bridge having an 8021q upper automatically? Let me give this a try.
On 9/30/2020 4:29 PM, Florian Fainelli wrote: > > > On 9/30/2020 1:43 PM, Vladimir Oltean wrote: >> On Wed, Sep 30, 2020 at 01:31:03PM -0700, Florian Fainelli wrote: >>> While we are it, call __vlan_find_dev_deep_rcu() which makes use the >>> VLAN group array which is faster. >> >> Not just "while at it", but I do wonder whether it isn't, in fact, >> called "deep" for a reason: >> >> /* >> * Lower devices of master uppers (bonding, team) do not have >> * grp assigned to themselves. Grp is assigned to upper device >> * instead. >> */ >> >> I haven't tested this, but I wonder if you could actually call >> __vlan_find_dev_deep_rcu() on the switch port interface and it would >> cover both this and the bridge having an 8021q upper automatically? > > Let me give this a try. We hit the if (vlan_info) branch and we do not recurse through the upper_dev because of that. I still need to send a v2 to remove the now unused 'iter' variable and fix up the bridge iproute2 command (there is no vlan_filtering=0 it is vlan_filtering 0).
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h index 0348dbab4131..3456b53d4d53 100644 --- a/net/dsa/dsa_priv.h +++ b/net/dsa/dsa_priv.h @@ -247,12 +247,10 @@ static inline struct sk_buff *dsa_untag_bridge_pvid(struct sk_buff *skb) * supports because vlan_filtering is 0. In that case, we should * definitely keep the tag, to make sure it keeps working. */ - netdev_for_each_upper_dev_rcu(dev, upper_dev, iter) { - if (!is_vlan_dev(upper_dev)) - continue; - - if (vid == vlan_dev_vlan_id(upper_dev)) - return skb; + upper_dev = __vlan_find_dev_deep_rcu(br, htons(proto), vid); + if (upper_dev) { + skb->vlan_proto = vlan_dev_vlan_proto(upper_dev); + return skb; } __vlan_hwaccel_clear_tag(skb);
The intent of 412a1526d067 ("net: dsa: untag the bridge pvid from rx skbs") is to transparently untag the bridge's default_pvid when the Ethernet switch can only support egress tagged of that default_pvid towards the CPU port. Prior to this commit, users would have to configure an 802.1Q upper on the bridge master device when the bridge is configured with vlan_filtering=0 in order to pop the VLAN tag: ip link add name br0 type bridge vlan_filtering=0 ip link add link br0 name br0.1 type vlan id 1 After this commit we added support for managing a switch port 802.1Q upper but those are not usually added as bridge members, and if they do, they do not actually require any special management, the data path would pop the desired VLAN tag accordingly. What we want to preserve is that use case and to manage when the user creates that 802.1Q upper for the bridge port. While we are it, call __vlan_find_dev_deep_rcu() which makes use the VLAN group array which is faster. As soon as we return the VLAN tagged SKB though it will be used by the following call path: netif_receive_skb_list_internal -> __netif_receive_skb_list_core -> __netif_receive_skb_core -> vlan_do_receive() which uses skb->vlan_proto, if we do not set it to the appropriate VLAN protocol, we will leave it set to what the DSA master has set (ETH_P_XDSA). Fixes: 412a1526d067 ("net: dsa: untag the bridge pvid from rx skbs") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> --- net/dsa/dsa_priv.h | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)