Subject: Re: [PATCH net-next 0/5] flower: match on the number of vlan tags

From: Boris Sukholitko <[email-masked]>
Date: Mon, 11 Apr 2022 17:56:47 +0300

On Mon, Apr 11, 2022 at 10:07:14AM -0400, Jamal Hadi Salim wrote:
> On 2022-04-11 09:30, Boris Sukholitko wrote:
> > Hi,
> > 
> > Our customers in the fiber telecom world have network configurations
> > where they would like to control their traffic according to the number
> > of tags appearing in the packet.
> > 
> > For example, TR247 GPON conformance test suite specification mostly
> > talks about untagged, single, double tagged packets and gives lax
> > guidelines on the vlan protocol vs. number of vlan tags.
> > 
> > This is different from the common IT networks where 802.1Q and 802.1ad
> > protocols are usually describe single and double tagged packet. GPON
> > configurations that we work with have arbitrary mix the above protocols
> > and number of vlan tags in the packet.
> > 
> > The following patch series implement number of vlans flower filter. They
> > add num_of_vlans flower filter as an alternative to vlan ethtype protocol
> > matching. The end result is that the following command becomes possible:
> > 
> > tc filter add dev eth1 ingress flower \
> >    num_of_vlans 1 vlan_prio 5 action drop
> > 
> 
> The idea looks sane. I guess flow dissector is now not just involving
> headers but metadata as well. I can see this applied to MPLS for example,
> etc.
> Can you please provide more elaborate example of more than 1 vlan?

Perusing our logs, we have redirect rules such as:

tc filter add dev $GPON ingress flower num_of_vlans $N \
   action mirred egress redirect dev $DEV

where N can range from 0 to 3 and $DEV is the function of $N.

Also there are rules setting skb mark based on the number of vlans:

tc filter add dev $GPON ingress flower num_of_vlans $N vlan_prio \
   $P action skbedit mark $M

> Where would the line be drawn:
> Is it max of two vlans?

We have seen the maximum of 3 vlans.

> Is there potential of <=X, meaning matching of upto X Vlans?
> 

We've managed to get by without such feature somehow :)

Thanks,
Boris.

> cheers,
> jamal