Follow up of Issue#356 <"Megaflow without vlan wc bits after Query the ofproto layer"> #359
Description
After further investigation into this issue, I observed that even after generating the correct megaflow for packets with dl_vlan, the problem persists. Specifically, when the first packet without dl_vlan generates a megaflow, subsequent packets with dl_vlan inadvertently match this existing megaflow instead of creating a new one. This suggests a wildcard masking issue: the initial packet’s processing clears the VLAN wildcard (WC) bit (by not requiring VLAN matching), and this WC state is cached. As a result, subsequent VLAN-tagged packets are processed with the same WC mask, causing their VLAN fields to be ignored.
In the previous discussion of Issue #356, you mentioned that the megaflow creation varies based on whether the wildcard (WC) bit is set. Could you further investigate the behavior of the WC bit in detail? For instance, when using netdev-dummy/receive to inject a packet without dl_vlan, does the WC bit get set to 0 and persist for future matches? What are the underlying rules governing how megaflow entries are matched?
I looked into the code of how eth_type and vlans are parsed in megaflow (I think it is in function odp_flow_format()), and I think megaflow takes the tpid in vlans as it eth_type and the real eth_type will be encaped if the packet has dl_vlan, however, if the vlans are ignored (in wc bits) the real eth_type will be used just like what it should be in packet without dl_vlan, could you please take a look into this too?