[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f9f01b3b-f6ab-ef82-6604-5dd8e925abea@nbd.name>
Date: Mon, 12 Jul 2021 12:18:26 +0200
From: Felix Fietkau <nbd@....name>
To: Pablo Neira Ayuso <pablo@...filter.org>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc: coreteam@...filter.org, davem@...emloft.net, fw@...len.de,
kadlec@...filter.org, kuba@...nel.org,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org, olek2@...pl, roid@...dia.com
Subject: Re: [PATCH nf] Revert "netfilter: flowtable: Remove redundant hw
refresh bit"
On 2021-07-12 11:46, Pablo Neira Ayuso wrote:
> Maybe the user reporting this issue is enabling the --hw option?
> As I said, the patch that is being proposed to be revert is just
> amplifying.
>
> The only way to trigger this bug that I can find is:
>
> - NF_FLOWTABLE_HW_OFFLOAD is enabled.
> - packets are following the software path.
>
> I don't see yet how this can happen with upstream codebase, nftables
> enables NF_FLOWTABLE_HW_OFFLOAD at configuration time, if the driver
> does not support for hardware offload, then NF_FLOWTABLE_HW_OFFLOAD is
> not set.
>
> Is xt_flowoffload rejecting the rule load if user specifies --hw and
> the hardware does not support for hardware offload?
>
> By reading Felix's discussion on the IRC, it seems to me he does not
> like that the packet path retries to offload flows. If so, it should
> be possible to add a driver flag to disable this behaviour, so driver
> developers select what they prefer that flowtable core retries to
> offload entries. I can have a look into adding such flag and use it
> from the mtk driver.
I'd prefer making the retry behavior depend on the error code during
setup. For example, if we get -ENOMEM, -EAGAIN or something like that,
we should definitely retry.
If we get -EOPNOTSUPP or -EINVAL, I don't think a retry makes any sense
on any driver.
- Felix
Powered by blists - more mailing lists