Mon, May 18, 2020 at 06:48:46PM CEST, ec...@solarflare.com wrote: >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).
Is it worth to have an object just for this particular purpose? In the past I was trying to push a tc block object that could be added/removed and being used to insert filters w/o being attached to any qdisc. This was frowned upon and refused because the existence of block does not have any meaning w/o being attached. What you suggest with zone sounds quite similar. More to that, it is related only to act_ct. Is it a good idea to have a common object in TC which is actually used as internal part of act_ct only? To be honest, I don't like the idea. > >WDYT? > >-ed
