On Fri, Aug 9, 2019 at 1:23 PM Justin Pettit <jpet...@ovn.org> wrote:
> > > On Aug 7, 2019, at 11:40 AM, Darrell Ball <dlu...@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 > > > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev