[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZPHZOKwPFflnqfFz@calendula>
Date: Fri, 1 Sep 2023 14:29:44 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Felix Fietkau <nbd@....name>
Cc: netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC] netfilter: nf_tables: ignore -EOPNOTSUPP on flowtable
device offload setup
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.
Powered by blists - more mailing lists