Hi,

On Tue, 12 Aug 2025, Junlong Wang wrote:

> 
> > > 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.

Understood. But is this the best course of action? Say, what happens if the user
passes ETH / IPV4 / UDP pattern items, where 'spec' and 'mask' are 'null' in all
the items? Theoretically, the driver could translate this to set the key to have
EtherType 0x0800/0xffff and IP protocol to be 0x11/0xff . Or am I wrong?

Thank you.
> 
> 
>