Received-SPF: pass (google.com: domain of linux-kernel+bounces-155786-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Tue, 23 Apr 2024 19:15:16 +0000
From: Daniel Machon <daniel.machon@microchip.com>
To: =?utf-8?Q?Asbj=C3=B8rn_Sloth_T=C3=B8nnesen?= <ast@fiberby.net>
CC: <netdev@vger.kernel.org>, Steen Hegelund <Steen.Hegelund@microchip.com>,
	Lars Povlsen <lars.povlsen@microchip.com>, <UNGLinuxDriver@microchip.com>,
	"David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	<linux-kernel@vger.kernel.org>, Jacob Keller <jacob.e.keller@intel.com>
Subject: Re: [PATCH net-next 1/2] net: sparx5: flower: cleanup
 sparx5_tc_flower_handler_control_usage()
Message-ID: <20240423191516.o6ssgqhrsk7hizdk@DEN-DL-M70577>
References: <20240423102728.228765-1-ast@fiberby.net>
 <20240423111515.wzvclnlxdwv77zy7@DEN-DL-M70577>
 <8e112b31-0168-4e82-a378-87211ea99cfa@fiberby.net>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8e112b31-0168-4e82-a378-87211ea99cfa@fiberby.net>

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