[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <64db5b99-2c67-750c-e5bd-79c7e426aaa2@solarflare.com>
Date: Mon, 18 May 2020 17:48:46 +0100
From: Edward Cree <ecree@...arflare.com>
To: Paul Blakey <paulb@...lanox.com>, Jiri Pirko <jiri@...nulli.us>
CC: Saeed Mahameed <saeedm@...lanox.com>,
Oz Shlomo <ozsh@...lanox.com>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
Vlad Buslov <vladbu@...lanox.com>,
David Miller <davem@...emloft.net>, <netdev@...r.kernel.org>,
Jiri Pirko <jiri@...lanox.com>, Roi Dayan <roid@...lanox.com>
Subject: Re: [PATCH net-next 0/3] net/sched: act_ct: Add support for
specifying tuple offload policy
On 18/05/2020 17:17, Paul Blakey wrote:
> But we think, as you pointed out, explicit as here is better, there is just no API to configure the flow table currently so we suggested this.
> Do you have any suggestion for an API that would be better?
I see two possible approaches. We could either say "conntrack is
part of netfilter, so this should be an nftnetlink API", or we
could say "this is about configuring TC offload (of conntracks),
so it belongs in a TC command". I lean towards the latter mainly
so that I don't have to install & learn netfilter commands (the
current conntrack offload can be enabled without touching them).
So it'd be something like "tc ct add zone 1 timeout 120 pkts 10",
and if a 'tc filter add' or 'tc action add' references a ct zone
that hasn't been 'tc ct add'ed, it gets automatically added with
the default policy (and if you come along later and try to 'tc ct
add' it you get an EBUSY or EEXIST or something).
WDYT?
-ed
Powered by blists - more mailing lists