On 30 September 2014 09:51, Ben Pfaff <b...@nicira.com> wrote: > 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 <joestrin...@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 <b...@nicira.com> >
I see, writing up a uid_equal() is straightforward, so that change into this patch. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
