On 9 November 2014 20:06, Pravin Shelar <pshe...@nicira.com> wrote:
> On Sat, Nov 8, 2014 at 4:37 PM, Joe Stringer <joestrin...@nicira.com>
> wrote:
> > On 8 November 2014 14:26, Pravin Shelar <pshe...@nicira.com> wrote:
> >>
> >> On Fri, Nov 7, 2014 at 3:55 PM, Joe Stringer <joestrin...@nicira.com>
> >> wrote:
> >> > 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.
> >> >> > ---
> >> >>
> >> >> Patch looks good. I have few comments:
> >> >
> >> >
> >> > Thanks for taking a look,
> >> >
> >> >>
> >> >> - Can you make union of unmasked_key and (fid, ufid_hash), since they
> >> >> are mutually exclusive.
> >> >
> >> >
> >> > Unmasked key may be used when UFID is part of the flow, eg if the full
> >> > flow
> >> > is requested in ovs_flow_cmd_fill_match(). It should still be
> populated
> >> > for
> >> > every flow.
> >> >
> >> Why userspace need to know unmasked key if ufids are used for the flow?
> >
> >
> > One example is when something like ovs-dpctl wants to dump all
> information
> > about all of the flows (which dumps unmasked_key and not the masked
> key). I
> > think this makes it more consistent with using the output of ovs-dpctl
> > dump-flows as the input for ovs-dpctl del-flow <foo>.
> >
> dpctl can dump the ufid and user can the id to delete flow.
>
> > This is also related to the dpif interface behaviour when both
> > (unmasked_key, ufid) are specified - eg for delete it first tries to
> index
> > by UFID, then if that fails, index by flow:
> > http://openvswitch.org/pipermail/dev/2014-October/047608.html
>
> We need to simplify the interface. We can either use ufid or unmasked
> key as id, but not both.
>
OK, I think this is workable. I will look into it.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
