[ovs-dev] [PATCHv6 10/14] dpif: Generate flow_hash for revalidators in dpif.

Ben Pfaff blp at nicira.com
Mon Sep 29 20:51:08 UTC 2014


On Fri, Sep 26, 2014 at 09:28:14PM +1200, Joe Stringer wrote:
> This patch shifts the responsibility for determining the hash for a flow
> from the revalidation logic down to the dpif layer. This assists in
> handling backward-compatibility for revalidation with the upcoming
> unique identifier "UID" patches, and allows ovs-dpctl to automatically
> determine flow hashes while keeping dpif logic separate from the
> ofproto-dpif logic.
> 
> A 128-bit UID was selected to minimize the likelihood of hash conflicts.
> Handler threads will not install a flow that has an identical UID as
> another flow, to prevent misattribution of stats and to ensure that the
> correct flow key cache is used for revalidation.
> 
> The UID for a flow is a 128-bit hash of the flow key. For datapaths that
> do not support UID, which is currently all datapaths, the dpif will
> generate the UID and pass it up during upcall and flow_dump. This is
> generated based on the datapath flow key.
> 
> Later patches will add support for datapaths to store and interpret this
> UID, in which case the dpif has a responsibility to pass it through
> transparently.
> 
> Signed-off-by: Joe Stringer <joestringer at nicira.com>
> ---
> v6: Split out from "dpif: Add Unique flow identifiers."
>     Store flow hash seed staticly for all dpifs.
>     Rebase.
> v5: Always pass flow_key down to dpif, to improve error logging.
>     Rebase.
> v4: Generate UID in dpif layer and pass up to ofproto-dpif-upcall.
>     Skip sending flow key in flow_del.
>     Combine dpif,upcall,dpif-netdev,dpif-linux changes into one patch.
> v3: Rebase.

Comparisons of uids here and in the previous patch generally use
memcmp().  memcmp() is usually written with a few assumptions in mind
that can make it slower than, say, something like (a->lo != b->lo ||
a->hi != b->hi) or ((a->lo ^ b->lo) | (a->hi ^ b->hi)).  The first
assumption is that the arguments might not be properly aligned (which
doesn't matter much on x86.  The second assumption is that memcmp() is
usually careful not to read more bytes than necessary to find a
mismatch, because that might read beyond the end of a page and
segfault.  (I'm not sure all implementations are careful that way.)
Anyone, writing a simple uid_equal() might be worth it.

Acked-by: Ben Pfaff <blp at nicira.com>



More information about the dev mailing list