cls_flower vlan matching

[Vlad Buslov <vladbu@nvidia.com>]

Hi Jiri,

I've been debugging an issue that we encounter with OvS-created rules
for single and double-VLAN packets.

Basically, for flows with single VLAN OvS creates following tc filter:

filter protocol 802.1Q pref 2 flower chain 0 
filter protocol 802.1Q pref 2 flower chain 0 handle 0x1 
  vlan_id 10                                                                                                            
  vlan_prio 0             
  vlan_ethtype ip                                                                                                       
  dst_mac e4:2c:0b:08:00:02     
  src_mac b8:ce:f6:05:e7:3a
  eth_type ipv4
  ip_flags nofrag                                                                                                       
  skip_hw                                                                                                               
  not_in_hw               
        action order 1: vlan  pop pipe                                                                                  
         index 2 ref 1 bind 1 installed 11 sec used 0 sec firstused 10 sec
        Action statistics:                     
        Sent 860 bytes 10 pkt (dropped 0, overlimits 0 requeues 0) 
        backlog 0b 0p requeues 0
        no_percpu

        action order 2: mirred (Egress Redirect to device enp8s0f0_0) stolen
        index 2 ref 1 bind 1 installed 11 sec used 0 sec firstused 10 sec
        Action statistics:
        Sent 860 bytes 10 pkt (dropped 0, overlimits 0 requeues 0) 
        backlog 0b 0p requeues 0
        cookie 16a9b603144b3e0c64a887aeb972a269
        no_percpu

Such rule also matches packets that have additional second VLAN header,
even though filter has both eth_type and vlan_ethtype set to "ipv4".
Looking at the code this seems to be mostly an artifact of the way
flower uses flow dissector. First, even though looking at the uAPI
eth_type and vlan_ethtype appear like a distinct fields, in flower they
are all mapped to the same key->basic.n_proto. Second, flow dissector
skips following VLAN header as no keys for FLOW_DISSECTOR_KEY_CVLAN are
set and eventually assigns the value of n_proto to last parsed header.
With these, such filters ignore any headers present between first VLAN
header and first "non magic" header (ipv4 in this case) that doesn't
result FLOW_DISSECT_RET_PROTO_AGAIN.

Is described behavior intentional? Any way to enforce matching for
header following the VLAN header?

Regards,
Vlad