[ovs-dev] [PATCHv6 12/14] dpif: Index flows using unique identifiers.

[Ben Pfaff]

On Fri, Sep 26, 2014 at 09:28:16PM +1200, Joe Stringer wrote:
> This patch modifies the dpif interface to allow flows to be manipulated
> using a 128-bit identifier. This allows revalidator threads to perform
> datapath operations faster, as they do not need to serialise the entire
> flow key for operations like flow_get and flow_delete. In conjunction
> with a future patch to simplify the dump interface, this provides a
> significant performance benefit for revalidation.
> 
> When handlers assemble flow_put operations, they specify a unique
> identifier (UID) for each flow as it is passed down to the datapath to
> be stored with the flow. The UID is currently provided to handlers
> by the dpif during upcall processing.
> 
> When revalidators assemble flow_get or flow_del operations, they specify
> the UID for the flow along with the key, and a boolean for whether to
> send the request using only a UID or to send the request using the UID
> and flow key. The former is preferred for newer datapaths that support
> UID, while the latter is used for backwards compatibility.

I don't think I understand 'terse'.  I guess that the caller uses the
'terse' flag if it knows that the datapath supports UIDs.  But can't
the datapath know that on its own, and use the key or not based on
that knowledge?  Then again, I see that some of the callers (e.g. the
feature probe functions) always pass false for 'terse'.  Does this
mean that sometimes the key should always be included?  I'm not quite
following the logic.

One point that I want to make sure is covered is startup.  We will
hash differently on every startup of Open vSwitch, because of the
random secret, so I want to make sure that the initial scan and dump
of the flow table from the revalidator thread will properly handle the
wrong UIDs on that initial scan.