[ovs-dev] [thread 12/15] ofproto-dpif: Lock rules to prevent eviction.

[Ethan Jackson]

> 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 at openvswitch.org