[RFC] netfilter: nf_tables: ignore -EOPNOTSUPP on flowtable device offload setup

[RFC] netfilter: nf_tables: ignore -EOPNOTSUPP on flowtable device offload setup

[Felix Fietkau]

On many embedded devices, it is common to configure flowtable offloading for
a mix of different devices, some of which have hardware offload support and
some of which don't.
The current code limits the ability of user space to properly set up such a
configuration by only allowing adding devices with hardware offload support to
a offload-enabled flowtable.
Given that offload-enabled flowtables also imply fallback to pure software
offloading, this limitation makes little sense.
Fix it by not bailing out when the offload setup returns -EOPNOTSUPP

Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
 net/netfilter/nf_tables_api.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 41b826dff6f5..dfa2ea98088b 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -8103,7 +8103,7 @@ static int nft_register_flowtable_net_hooks(struct net *net,
 		err = flowtable->data.type->setup(&flowtable->data,
 						  hook->ops.dev,
 						  FLOW_BLOCK_BIND);
-		if (err < 0)
+		if (err < 0 && err != -EOPNOTSUPP)
 			goto err_unregister_net_hooks;
 
 		err = nf_register_net_hook(net, &hook->ops);
-- 
2.41.0

Re: [RFC] netfilter: nf_tables: ignore -EOPNOTSUPP on flowtable device offload setup

[Pablo Neira Ayuso]

Hi Felix,

On Thu, Aug 31, 2023 at 10:14:20PM +0200, Felix Fietkau wrote:
> On many embedded devices, it is common to configure flowtable offloading for
> a mix of different devices, some of which have hardware offload support and
> some of which don't.
> The current code limits the ability of user space to properly set up such a
> configuration by only allowing adding devices with hardware offload support to
> a offload-enabled flowtable.
> Given that offload-enabled flowtables also imply fallback to pure software
> offloading, this limitation makes little sense.
> Fix it by not bailing out when the offload setup returns -EOPNOTSUPP

Would you send a v2 to untoggle the offload flag when listing the
ruleset if EOPNOTSUPP is reported? Thus, the user knows that no
hardware offload is being used.

> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> ---
>  net/netfilter/nf_tables_api.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
> index 41b826dff6f5..dfa2ea98088b 100644
> --- a/net/netfilter/nf_tables_api.c
> +++ b/net/netfilter/nf_tables_api.c
> @@ -8103,7 +8103,7 @@ static int nft_register_flowtable_net_hooks(struct net *net,
>  		err = flowtable->data.type->setup(&flowtable->data,
>  						  hook->ops.dev,
>  						  FLOW_BLOCK_BIND);
> -		if (err < 0)
> +		if (err < 0 && err != -EOPNOTSUPP)
>  			goto err_unregister_net_hooks;
>  
>  		err = nf_register_net_hook(net, &hook->ops);
> -- 
> 2.41.0
> 

Re: [RFC] netfilter: nf_tables: ignore -EOPNOTSUPP on flowtable device offload setup

[Felix Fietkau]

On 01.09.23 10:39, Pablo Neira Ayuso wrote:
> Hi Felix,
> 
> On Thu, Aug 31, 2023 at 10:14:20PM +0200, Felix Fietkau wrote:
>> On many embedded devices, it is common to configure flowtable offloading for
>> a mix of different devices, some of which have hardware offload support and
>> some of which don't.
>> The current code limits the ability of user space to properly set up such a
>> configuration by only allowing adding devices with hardware offload support to
>> a offload-enabled flowtable.
>> Given that offload-enabled flowtables also imply fallback to pure software
>> offloading, this limitation makes little sense.
>> Fix it by not bailing out when the offload setup returns -EOPNOTSUPP
> 
> Would you send a v2 to untoggle the offload flag when listing the
> ruleset if EOPNOTSUPP is reported? Thus, the user knows that no
> hardware offload is being used.

Wouldn't that mess up further updates to the flowtable? From what I can 
tell, when updating a flow table, changing its offload flag is not 
supported.

- Felix

Re: [RFC] netfilter: nf_tables: ignore -EOPNOTSUPP on flowtable device offload setup

[Pablo Neira Ayuso]

On Fri, Sep 01, 2023 at 12:30:37PM +0200, Felix Fietkau wrote:
> On 01.09.23 10:39, Pablo Neira Ayuso wrote:
> > Hi Felix,
> > 
> > On Thu, Aug 31, 2023 at 10:14:20PM +0200, Felix Fietkau wrote:
> > > On many embedded devices, it is common to configure flowtable offloading for
> > > a mix of different devices, some of which have hardware offload support and
> > > some of which don't.
> > > The current code limits the ability of user space to properly set up such a
> > > configuration by only allowing adding devices with hardware offload support to
> > > a offload-enabled flowtable.
> > > Given that offload-enabled flowtables also imply fallback to pure software
> > > offloading, this limitation makes little sense.
> > > Fix it by not bailing out when the offload setup returns -EOPNOTSUPP
> > 
> > Would you send a v2 to untoggle the offload flag when listing the
> > ruleset if EOPNOTSUPP is reported? Thus, the user knows that no
> > hardware offload is being used.
> 
> Wouldn't that mess up further updates to the flowtable? From what I can
> tell, when updating a flow table, changing its offload flag is not
> supported.

The flag would be untoggled if hardware offload is not supported. What
problematic scenario are you having in mind that might break?

In any case, there is a need to provide a way to tell the user if the
hardware offload is actually happening or not, if not what I suggest,
then propose a different way. But user really needs to know if it runs
software or hardware plane to debug issues.

Re: [RFC] netfilter: nf_tables: ignore -EOPNOTSUPP on flowtable device offload setup

[Felix Fietkau]

On 01.09.23 14:29, Pablo Neira Ayuso wrote:
> On Fri, Sep 01, 2023 at 12:30:37PM +0200, Felix Fietkau wrote:
>> On 01.09.23 10:39, Pablo Neira Ayuso wrote:
>> > Hi Felix,
>> > 
>> > On Thu, Aug 31, 2023 at 10:14:20PM +0200, Felix Fietkau wrote:
>> > > On many embedded devices, it is common to configure flowtable offloading for
>> > > a mix of different devices, some of which have hardware offload support and
>> > > some of which don't.
>> > > The current code limits the ability of user space to properly set up such a
>> > > configuration by only allowing adding devices with hardware offload support to
>> > > a offload-enabled flowtable.
>> > > Given that offload-enabled flowtables also imply fallback to pure software
>> > > offloading, this limitation makes little sense.
>> > > Fix it by not bailing out when the offload setup returns -EOPNOTSUPP
>> > 
>> > Would you send a v2 to untoggle the offload flag when listing the
>> > ruleset if EOPNOTSUPP is reported? Thus, the user knows that no
>> > hardware offload is being used.
>> 
>> Wouldn't that mess up further updates to the flowtable? From what I can
>> tell, when updating a flow table, changing its offload flag is not
>> supported.
> 
> The flag would be untoggled if hardware offload is not supported. What
> problematic scenario are you having in mind that might break?

The scenario I'm thinking about is this:
Initially, the flowtable is created with a set of devices which don't 
support offload.
Afterwards, the flowtable gets updated with the intention of adding an 
extra device which *does* support hw offload to the existing flowtable.
If the flag was cleared after initially creating the table, I think the 
update would fail. Or did I misread the code?

> In any case, there is a need to provide a way to tell the user if the
> hardware offload is actually happening or not, if not what I suggest,
> then propose a different way. But user really needs to know if it runs
> software or hardware plane to debug issues.

In my opinion, a single flag indication for the flow table is mostly 
useless. Much more useful would be if you could query which of the 
devices that were added to the flowtable support hw offload and which 
ones don't. That requires some API changes though, and I don't think 
that should be done in this patch.

- Felix