<br />> > 1) If both 'spec' and 'mask' are 'NULL', shouldn't the code set some broader<br />> > match on the sole presence of a Ethernet header?<br />> > 2) If 'mask' is 'NULL' and 'spec' is not (or vice versa), isn't this an error?<br /> <br />> >> +            break;<br />> >> +        case RTE_FLOW_ITEM_TYPE_VLAN:<br />> >> +            vlan_spec = item->spec;<br />> >> +            vlan_mask = item->mask;<br />> >> +            if (vlan_spec && vlan_mask) {<br />> >> +                key->vlan_tci  = vlan_spec->tci;<br />> >> +                key_mask->vlan_tci = vlan_mask->tci;<br />> >> +            }<br />> >  <br />> >  In my opinion, The values of 'spec' and 'mask' will not be null.<br />> >  If the user does not set 'spec' and 'mask', the passed-in values will be set to 00 and ff by default,<br />> >  which is ensured by the upper-layer interface of dpdk.<br /> <br />> Wait a minute.. does this mean that if the user passes, say, ETH / IPV4 / UDP<br />> pattern and the 'spec' and 'mask' of ETH are both 'null', the actual key/mask<br />> values in the HW rule will be, say, for the EtherType, '0000' and 'ffff'?<br />> Is this correct? And which part of DPDK interface envisages that?<br /> <br />> Again, may be it's just my misunderstanding.<br /> <br /> Sorry, I misunderstood and caused you inconvenience.<br /> If the user does not set 'spec' and 'mask', we will set 'spec' '0000' and mask 'ffff' write fd table to HW,<br /> not set by DPDK interface.<br /> If the user set one of 'spec' and 'mask', we will also set 'spec' '0000' and mask 'ffff' write fd table to HW.<br /> This is how we handle it.<br /> <br />