On 3/30/23 10:17, Naveen Yerramneni wrote:
> Add OpenFlow extn to set conntrack entries limit per zone.
> This extn will be used in future to set the zone level limit for
> drop zones used by OVN.
> 
> Signed-off-by: Naveen Yerramneni <[email protected]>
> Reviewed-by: Simon Horman <[email protected]>
> ---
> Notes:
>   v1 -> v2
>   - Fix memory leak and added logs
>   v2 -> v3
>   - Addressed nits
>   v3 -> v4
>   - Updated change description
> 
>  NEWS                           |  2 ++
>  include/openflow/nicira-ext.h  | 10 ++++++++++
>  include/openvswitch/ofp-msgs.h |  4 ++++
>  lib/ofp-bundle.c               |  1 +
>  lib/ofp-print.c                | 11 +++++++++++
>  lib/rconn.c                    |  1 +
>  ofproto/ofproto-dpif.c         | 21 +++++++++++++++++++++
>  ofproto/ofproto-provider.h     |  4 ++++
>  ofproto/ofproto.c              | 25 +++++++++++++++++++++++++
>  tests/ofp-print.at             | 10 ++++++++++
>  tests/ovs-ofctl.at             | 12 ++++++++++++
>  utilities/ovs-ofctl.8.in       |  5 +++++
>  utilities/ovs-ofctl.c          | 34 ++++++++++++++++++++++++++++++++++
>  13 files changed, 140 insertions(+)
> 
> diff --git a/NEWS b/NEWS
> index fe6055a27..f6ae60856 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -32,6 +32,8 @@ v3.1.0 - xx xxx xxxx
>     - OpenFlow:
>       * New OpenFlow extension NXT_CT_FLUSH to flush connections matching
>         the specified fields.
> +     * New OpenFlow extension NXT_CT_SET_ZONE_LIMIT to set conntrack table
> +       limit at zone level.

Hi, Naveen.  Sorry for the late reply, but I don't think this functionality
should be implemented within OpenFlow interface.

OpenFlow is not great for configurations that should preserve the state on
re-start, for example.  CT_FLUSH is reasonable to implement via OpenFlow,
because it is a one-shot stateless command.  But limits are stateful.  We
should be able to request a current value and save and restore the
configuration on re-start with ovs-save script.  This is not ideal.

What we should do instead is to naturally extend the existing database
configuration that already supports per-zone configuration of conntrack
timeouts.  That will be more organic within OVS and will solve the problem
with configuration persistence.

See the CT_Zone and CT_Timeout_Policy database columns.

Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to