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

[Darrell Ball]

On Fri, Aug 9, 2019 at 1:23 PM Justin Pettit <jpettit at ovn.org> wrote:

>
> > 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.
>

I spotted the other e-mail.


>
> > 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.
>

yep


>
> > 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.
>

I am not overly concerned about '3' in general for the userspace datapath
since vswitchd restart will wipe out the dynamic u32 profile IDs anyways
and they will need to be re-associated, so they should be tightly coupled
to the database uuids.


>
> Thanks,
>
> --Justin
>
>
>