From: "Asbjørn Sloth Tønnesen" <ast@fiberby.net>
To: Louis Peens <louis.peens@corigine.com>
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 11:13:22 +0000 [thread overview]
Message-ID: <2c7bc566-c975-4dd8-a17c-10c7b9ff3928@fiberby.net> (raw)
In-Reply-To: <ZhT/E1qDsMmMxGwb@LouisNoVo>
Hi Louis,
On 4/9/24 8:40 AM, Louis Peens wrote:
> 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.
I agree, I will update the naming in v2:
flow_rule_no_unsupp_control_flags => flow_rule_is_supp_control_flags
flow_rule_no_control_flags + s/no/has/ => flow_rule_has_control_flags
flow_rule_match_no_control_flags + s/no/has/ => flow_rule_match_has_control_flags
--
Best regards
Asbjørn Sloth Tønnesen
Network Engineer
Fiberby - AS42541
next prev parent reply other threads:[~2024-04-09 11:13 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
2024-04-09 11:13 ` Asbjørn Sloth Tønnesen [this message]
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=2c7bc566-c975-4dd8-a17c-10c7b9ff3928@fiberby.net \
--to=ast@fiberby.net \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--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=louis.peens@corigine.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox