> > 1) If both 'spec' and 'mask' are 'NULL', shouldn't the code set some broader
> > match on the sole presence of a Ethernet header?
> > 2) If 'mask' is 'NULL' and 'spec' is not (or vice versa), isn't this an error?

> >> +            break;
> >> +        case RTE_FLOW_ITEM_TYPE_VLAN:
> >> +            vlan_spec = item->spec;
> >> +            vlan_mask = item->mask;
> >> +            if (vlan_spec && vlan_mask) {
> >> +                key->vlan_tci  = vlan_spec->tci;
> >> +                key_mask->vlan_tci = vlan_mask->tci;
> >> +            }
> > 
> >  In my opinion, The values of 'spec' and 'mask' will not be null.
> >  If the user does not set 'spec' and 'mask', the passed-in values will be set to 00 and ff by default,
> >  which is ensured by the upper-layer interface of dpdk.

> Wait a minute.. does this mean that if the user passes, say, ETH / IPV4 / UDP
> pattern and the 'spec' and 'mask' of ETH are both 'null', the actual key/mask
> values in the HW rule will be, say, for the EtherType, '0000' and 'ffff'?
> Is this correct? And which part of DPDK interface envisages that?

> Again, may be it's just my misunderstanding.

 Sorry, I misunderstood and caused you inconvenience.
 If the user does not set 'spec' and 'mask', we will set 'spec' '0000' and mask 'ffff' write fd table to HW,
 not set by DPDK interface.
 If the user set one of 'spec' and 'mask', we will also set 'spec' '0000' and mask 'ffff' write fd table to HW.
 This is how we handle it.