On 7 November 2014 14:15, Pravin Shelar <pshe...@nicira.com> wrote:
> On Fri, Oct 31, 2014 at 4:55 PM, Joe Stringer <joestrin...@nicira.com>
> wrote:
> > If a datapath is created with the flag OVS_DP_F_INDEX_BY_UFID, then an
> > additional table_instance is added to the flow_table, which is indexed
> > by unique identifiers ("UFID"). Userspace implementations can specify a
> > UFID of up to 128 bits along with a flow operation as shorthand for the
> > key. This allows revalidation performance improvements of up to 50%.
> >
> > If a datapath is created using OVS_DP_F_INDEX_BY_UFID and a UFID is not
> > specified at flow setup time, then that operation will fail. If
> > OVS_UFID_F_* flags are specified for an operation, then they will modify
> > what is returned through the operation. For instance, OVS_UFID_F_SKIP_KEY
> > allows the datapath to skip returning the key (eg, during dump to reduce
> > memory copy).
> >
> > Signed-off-by: Joe Stringer <joestrin...@nicira.com>
> > ---
> > v9: No change.
> > v8: Rename UID -> UFID "unique flow identifier".
> > Fix null dereference when adding flow without uid or mask.
> > If UFID and not match are specified, and lookup fails, return ENOENT.
> > Rebase.
> > v7: Remove OVS_DP_F_INDEX_BY_UID.
> > Rework UID serialisation for variable-length UID.
> > Log error if uid not specified and OVS_UID_F_SKIP_KEY is set.
> > Rebase against "probe" logging changes.
> > v6: Fix documentation for supporting UIDs between 32-128 bits.
> > Minor style fixes.
> > Rebase.
> > v5: No change.
> > v4: Fix memory leaks.
> > Log when triggering the older userspace issue above.
> > v3: Initial post.
> > ---
>
>
By the way, this:
> Patch looks good. I have few comments:
> - Can you make union of unmasked_key and (fid, ufid_hash), since they
> are mutually exclusive.
>
And this:
> - ovs_flow_tbl_destroy() can iterate flow table and delete both hash
> entries. that way there is no need to iterate both tables.
Seem to conflict. If we're not keeping the flow in both tables, then we'll
need to iterate both.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
