[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZCNQ0YqLR3OxMgd3@salvia>
Date: Tue, 28 Mar 2023 22:40:49 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Paul Blakey <paulb@...dia.com>
Cc: Jozsef Kadlecsik <kadlec@...filter.org>,
Florian Westphal <fw@...len.de>,
netfilter-devel@...r.kernel.org, Oz Shlomo <ozsh@...dia.com>,
Roi Dayan <roid@...dia.com>, Vlad Buslov <vladbu@...dia.com>,
Saeed Mahameed <saeedm@...dia.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, coreteam@...filter.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH nf-next 1/1] netfilter: ctnetlink: Support offloaded
conntrack entry deletion
Hi Paul,
Apologies for lagging to catch up with this.
On Wed, Mar 22, 2023 at 09:35:32AM +0200, Paul Blakey wrote:
> Currently, offloaded conntrack entries (flows) can only be deleted
> after they are removed from offload, which is either by timeout,
> tcp state change or tc ct rule deletion. This can cause issues for
> users wishing to manually delete or flush existing entries.
>
> Support deletion of offloaded conntrack entries.
>
> Example usage:
> # Delete all offloaded (and non offloaded) conntrack entries
> # whose source address is 1.2.3.4
> $ conntrack -D -s 1.2.3.4
> # Delete all entries
> $ conntrack -F
This fine with me.
I think probably it much be documented somewhere that in case of
hardware offload, deletion is asynchronous.
Powered by blists - more mailing lists