Re: [PATCH net-next ct-offload 02/13] net/sched: act_ct: Instantiate flow table entry actions

[Edward Cree <ecree@solarflare.com>]

On 06/03/2020 13:22, Paul Blakey wrote:
> On 06/03/2020 13:35, Edward Cree wrote:
>> I'm not quite sure what the zone is doing in the action.  Surely it's
>>  a property of the match.  Or does this set a ct_zone for a potential
>>  *second* conntrack lookup?
> this is part of the metadata that driver should mark the with, as it can be matched against in following hardware tables/rules. consider this set of offloaded rules:
<snip>
So, normally I'd expect to use different chains for the different zones.
But I can see that in theory you might want to have some rules shared by
 both, hence being able to put them in the same chain is useful.

Assuming an idealised model of the hardware, with three stages:
* "left-hand rule" - in chain 0, match -trk, action "ct and goto chain"
* "conntrack lookup" - match 5-tuple, return NATted 5-tuple + some flags
* "right-hand rule" - in chain !=0, match +trk(±others), many actions
The zone is set by the left-hand rule, it's a (semi-)implicit input to
 the conntrack lookup, and it can be an explicit match field of the
 right-hand rule (as it is in your example).
But from a logical perspective, the conntrack lookup isn't *producing*
 the zone as an output, it's just forwarding on the zone that was fed to
 it by the left-hand rule.
So, the conntrack entry, which already has the zone in its
 struct flow_match (. struct flow_match_ct .key->ct_zone), doesn't need
 to specify the zone *again* in the action.  If the driver needs to
 supply that piece of information a second time in the action metadata
 for the conntrack action, that's a hardware-specific implementation
 detail.
Or so it seems to me, anyway.

-ed