> 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.
Well this is partially true. Previously if someone had a learn action the flow tables could change transiently. At any rate my thinking is that if we're in a situation where we've got inconsistent actions because of a transiently broken flow table, a will be happening soon which will fix things up. Perhaps there's a better way to do it though, but I'm not sure what it'd 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? X-CudaMail-Whitelist-To: dev@openvswitch.org _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
