> 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
"a revalidation will" I meant. > 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
