All of lore.kernel.org
 help / color / mirror / Atom feed
From: Louis Peens <louis.peens@corigine.com>
To: "Asbjørn Sloth Tønnesen" <ast@fiberby.net>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Taras Chornyi <taras.chornyi@plvision.eu>,
	Woojung Huh <woojung.huh@microchip.com>,
	UNGLinuxDriver@microchip.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Yanguo Li <yanguo.li@corigine.com>,
	oss-drivers@corigine.com, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	Edward Cree <ecree.xilinx@gmail.com>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Jiri Pirko <jiri@resnulli.us>
Subject: Re: [PATCH net-next 1/6] flow_offload: add flow_rule_no_unsupp_control_flags()
Date: Tue, 9 Apr 2024 10:40:51 +0200	[thread overview]
Message-ID: <ZhT/E1qDsMmMxGwb@LouisNoVo> (raw)
In-Reply-To: <20240408130927.78594-2-ast@fiberby.net>

On Mon, Apr 08, 2024 at 01:09:19PM +0000, Asbjørn Sloth Tønnesen wrote:
> [Some people who received this message don't often get email from ast@fiberby.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> This helper can be used by drivers to check for the
> presence of unsupported control flags.
> 
> It mirrors the existing check done in sfc:
>   drivers/net/ethernet/sfc/tc.c +276
> 
> This is aimed at drivers, which implements some control flags.
> 
> This should also be used by drivers that implement all
> current flags, so that future flags will be unsupported
> by default.
> 
> Only compile-tested.
> 
> Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
> ---
>  include/net/flow_offload.h | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
> index 314087a5e1818..c1317b14da08c 100644
> --- a/include/net/flow_offload.h
> +++ b/include/net/flow_offload.h
> @@ -449,6 +449,28 @@ static inline bool flow_rule_match_key(const struct flow_rule *rule,
>         return dissector_uses_key(rule->match.dissector, key);
>  }
> 
> +/**
> + * flow_rule_no_unsupp_control_flags() - check for unsupported control flags
> + * @supp_flags: flags supported by driver
> + * @flags: flags present in rule
> + * @extack: The netlink extended ACK for reporting errors.
> + *
> + * Returns true if only supported control flags are set, false otherwise.
> + */
> +static inline bool flow_rule_no_unsupp_control_flags(const u32 supp_flags,
> +                                                    const u32 flags,
> +                                                    struct netlink_ext_ack *extack)
Thanks for the change Asbjørn, I like the series in general. I do have
some nitpicking with the naming of this function, the double negative
makes it a bit hard to read. Especially where it gets used, where it
then reads as:
    'if not no unsupported'

I think something like:
    'if not supported'
or
    'if unsupported'

will read much better - personally I think the first option is the best,
otherwise you might end up with 'if not unsupported', which is also
weird.

Some possible suggestions I can think of:
    flow_rule_control_flags_is_supp()
    flow_rule_is_supp_control_flags()
    flow_rule_check_supp_control_flags()

or perhaps some even better variant of this. I hope it's not just me, if
that's the case please feel free to ignore.

  parent reply	other threads:[~2024-04-09  8:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-08 13:09 [PATCH net-next 0/6] flower: validate control flags Asbjørn Sloth Tønnesen
2024-04-08 13:09 ` [PATCH net-next 1/6] flow_offload: add flow_rule_no_unsupp_control_flags() Asbjørn Sloth Tønnesen
2024-04-09  1:56   ` Baowen Zheng
2024-04-09 11:27     ` Asbjørn Sloth Tønnesen
2024-04-09  2:05   ` Baowen Zheng
2024-04-09  8:40   ` Louis Peens [this message]
2024-04-09 11:13     ` Asbjørn Sloth Tønnesen
2024-04-10  5:10       ` Louis Peens
2024-04-08 13:09 ` [PATCH net-next 2/6] nfp: flower: fix check for unsupported control flags Asbjørn Sloth Tønnesen
2024-04-08 13:09 ` [PATCH net-next 3/6] flow_offload: add flow_rule_no_control_flags() Asbjørn Sloth Tønnesen
2024-04-09  2:09   ` Baowen Zheng
2024-04-09 11:31     ` Asbjørn Sloth Tønnesen
2024-04-09 11:35       ` Baowen Zheng
2024-04-08 13:09 ` [PATCH net-next 4/6] net: prestera: flower: validate control flags Asbjørn Sloth Tønnesen
2024-04-08 13:09 ` [PATCH net-next 5/6] flow_offload: add flow_rule_match_no_control_flags() Asbjørn Sloth Tønnesen
2024-04-08 13:09 ` [PATCH net-next 6/6] net: dsa: microchip: ksz9477: flower: validate control flags Asbjørn Sloth Tønnesen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZhT/E1qDsMmMxGwb@LouisNoVo \
    --to=louis.peens@corigine.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=ast@fiberby.net \
    --cc=davem@davemloft.net \
    --cc=ecree.xilinx@gmail.com \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=oss-drivers@corigine.com \
    --cc=pabeni@redhat.com \
    --cc=taras.chornyi@plvision.eu \
    --cc=woojung.huh@microchip.com \
    --cc=xiyou.wangcong@gmail.com \
    --cc=yanguo.li@corigine.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.