[ovs-dev] [PATCH v2 5/9] ofproto-dpif: Consume CT_Zone, and CT_Timeout_Policy tables

Justin Pettit jpettit at ovn.org
Fri Aug 9 20:23:51 UTC 2019


> On Aug 7, 2019, at 11:40 AM, Darrell Ball <dlu998 at gmail.com> wrote:
> 
> There are 3 behaviors with the patchset that are datapath specific
> 
> 1/ Unwildcarding of commit flows with timeout policies
>     As we discussed, the userspace conntrack does not need to do this and would not since it is suboptimal
>     since unnecessary flows are generated.
>     This is because userspace conntrack would use a single shared profile across all dl_types and ip_proto
>     rather than expanding to 6 profiles as in the case of kernel across dl_types and ip_protos.

That makes sense.  Based on this feedback, Yi-Hung and I came up with a design that I think will address this in v3.

> 2/ Userspace datepath/conntrack can easily manage cleanup of deleted profiles using a refcount approach.
>     For userspace conntrack, we don't need to read all the timeouts profiles continually and to continually try to
>     delete them from top down hoping to catch a window when the profile is not referenced by a flow.

Yes, I think we don't need to introduce ct_zone_timeout_policy_sweep(), and it can just be implemented in the existing dpif_netlink_run().  That should be in v3.

> 3/ In terms of timeout profile naming in userspace conntrack, we don't need to manage a separate profile ID space for
>     userspace conntrack. We can simply use the uuid directly. This simplifies the management of profiles and always
>      keeps knowledge of the profile name in sync across layers.

I'm hesitant to use the OVSDB row UUIDs in the dpif layer.  v3 is going to restructure the handling of timeout policies pretty significantly, so let's discuss the particulars once that's out.

Thanks,

--Justin




More information about the dev mailing list