[ovs-dev] [PATCH 00/12] Support zone-based conntrack timeout policy

Ilya Maximets i.maximets at samsung.com
Thu Aug 1 16:20:35 UTC 2019


On 31.07.2019 22:49, Justin Pettit wrote:
> 
>> On Jul 31, 2019, at 1:25 AM, Ilya Maximets <i.maximets at samsung.com> wrote:
>>
>> On 29.07.2019 21:53, Yi-Hung Wei wrote:
>>>
>>> As for the database schema, we intend to make CT_Zone table references
>>> to CT_Timeout_Policy table because some other zone-based feature can
>>> be configured through ovsdb later on. For example, we can have a new
>>> column in CT_Zone table that stores 'limit' as an integer to support
>>> the zone limit feature (limiting number of connection in a zone).  It
>>> is currently configured through dpctl commands.
>>
>> At least, since each zone could have only one timeout policy it's easy to just
>> inline CT_Timeout_Policy into CT_Zone like this:
> 
> The reason we arranged it like this is that we wanted to be able to allow per-flow timeout policies later.  The idea is that in the Bridge or Datapath table we could have a column that goes from integer to timeout policy row.  Those integers could then be used in OpenFlow ct(commit) actions.  This would allow a hierarchy of timeout policies from flow -> zone -> system.

Thanks for explanation. So, you're going to have some timeout policies that
will not be assigned to any zone, but will be used by the flow rules directly.
I'm not a conntrack expert, so I will not insist on simplification.
But I'm curious, do you have some real-world use-cases for such a complex
3-level configuration? For me, it looks like most of the users will just
configure a few zones and it'll be enough. Also, it might be not so easy to
properly configure everything since flow will not control values stored
in policy. It's hard for me to imagine why we can't just create enough number
of different zones and use them than needed. Is there a hard limit on number
of zones? I see that in kernel 'zone' is u16, so it seems fairly large.

Best regards, Ilya Maximets.


More information about the dev mailing list