Re: [PATCH net-next 1/2] net: sparx5: flower: cleanup sparx5_tc_flower_handler_control_usage()

[Daniel Machon]

> > > -       if (mt.mask->flags) {
> > > +       if (mt.mask->flags & (FLOW_DIS_IS_FRAGMENT | FLOW_DIS_FIRST_FRAG)) {
> > 
> > Since these flags are used here and in the next patch, maybe assign them
> > to a variable:
> > 
> > u32 supp_flags = FLOW_DIS_IS_FRAGMENT | FLOW_DIS_FIRST_FRAG
> > 
> > And update the use throughout.
> 
> In an earlier state this patch had a #define SPARX5_FLOWER_SUPPORTED_CTLFLAGS,
> in the same style as nfp in drivers/net/ethernet/netronome/nfp/flower/offload.c
> 
> Right now, this driver supports all currently defined flags (which are used with mask),
> so the point of using flow_rule_is_supp_control_flags() to this dirver, is to
> make it possible to introduce new flags in the future, without having to update
> all drivers to explicitly not support a new flag.
> 
> My problem with using supp_flags in both places is: What happens when support
> for a new flag is introduced?
> 
> u32 supp_flags = FLOW_DIS_IS_FRAGMENT | FLOW_DIS_FIRST_FRAG | FLOW_DIS_NEW_FLAG;
> 
> if (mt.mask->flags & (FLOW_DIS_IS_FRAGMENT | FLOW_DIS_FIRST_FRAG))
>         /* handle fragment flags through lookup table */
> 
> if (mt.mask->flags & FLOW_DIS_NEW_FLAG)
>         /* do something */
> 
> if (!flow_rule_is_supp_control_flags(supp_flags, mt.mask->flags, extack))
>         return -EOPNOTSUPP;
> 
> The fragment lookup table code currently requires the above guarding,
> as [0][0] in the lookup table is FRAG_INVAL, and not FRAG_SHRUG.
> 
> What do you think?

Yes - lets only check for fragment flags when doing the lookup. I am
fine with your original impl.

If you can fix the remaining issue, I will take the patches for a test
spin tomorrow.

Thanks!

> 
> --
> Best regards
> Asbjørn Sloth Tønnesen
> Network Engineer
> Fiberby - AS42541