On Thu, Aug 08, 2013 at 03:51:05PM -0700, Ben Pfaff wrote: > On Thu, Aug 08, 2013 at 12:58:31PM -0700, Ethan Jackson wrote: > > This patch uses a read-write lock to prevent rules from being evicted > > while they're used by child threads. > > > > Signed-off-by: Ethan Jackson <et...@nicira.com> > > I don't think anything ever destroys 'evict'. (But POSIX says that > only an unlocked rwlock may be destroyed.) > > This line in add_flow() should not compile: > ovs_rwlock_wrlock(&evict->evict) > but we have a buggy macro. I sent out a fix for the macro: > http://openvswitch.org/pipermail/dev/2013-August/030509.html
Previously, the processing of a given packet or flow always saw a consistent set of flow tables. That is, the flow tables didn't change from one lookup (e.g. resubmit) to another. I am not sure that this is true any longer. Is it now possible for a flow_mod to take effect in the middle of a packet's processing? At first glance, it seems to be. The new failure case in ofproto_delete_flow() looks like a problem for fail-open, which never retries because previously it could never fail. Is there a reason we can't block waiting for the write lock here? The uses of ofproto_delete_flow() (in-band, fail-open) are not performance sensitive fast paths. Ditto for ofproto_flush__(). I think that some of the changes here are because Clang can't annotate a return value as acquired. If so, would you mind mentioning that in the commit message? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
