Re: [ovs-dev] [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
On Wed, Dec 10, 2014 at 10:15 AM, Joe Stringer wrote: > On 9 December 2014 at 22:11, Pravin Shelar wrote: >> On Tue, Dec 9, 2014 at 4:25 PM, Joe Stringer wrote: >>> On 9 December 2014 at 10:32, Pravin Shelar wrote: On Tue, Dec 2, 2014 at 6:56 PM, Joe Stringer wrote: > @@ -424,10 +475,9 @@ static struct sw_flow *masked_flow_lookup(struct > table_instance *ti, > ovs_flow_mask_key(&masked_key, unmasked, mask); > hash = flow_hash(&masked_key, key_start, key_end); > head = find_bucket(ti, hash); > - hlist_for_each_entry_rcu(flow, head, hash_node[ti->node_ver]) { > - if (flow->mask == mask && flow->hash == hash && > - flow_cmp_masked_key(flow, &masked_key, > - key_start, key_end)) > + hlist_for_each_entry_rcu(flow, head, > flow_hash.node[ti->node_ver]) { > + if (flow->mask == mask && flow->flow_hash.hash == hash && > + flow_cmp_masked_key(flow, &masked_key, key_start, > key_end)) > return flow; > } > return NULL; > @@ -469,7 +519,40 @@ struct sw_flow *ovs_flow_tbl_lookup_exact(struct > flow_table *tbl, > /* Always called under ovs-mutex. */ > list_for_each_entry(mask, &tbl->mask_list, list) { > flow = masked_flow_lookup(ti, match->key, mask); > - if (flow && ovs_flow_cmp_unmasked_key(flow, match)) /* > Found */ > + if (flow && !flow->ufid && why not NULL check for flow->unmasked_key here rather than ufid? >>> >>> In this version, I tried to consistently use flow->ufid as the switch >>> for whether UFID exists or not. In the next version, this statement >>> would refer to flow->id->ufid_len. >>> >>> The current approach means that ovs_flow_tbl_lookup_exact() is really >>> ovs_flow_tbl_lookup_unmasked_key(). Do you think this should remain >>> specific to unmasked key or should it be made to check that the >>> identifier (ufid OR unmasked key) is the same? >> >> It is easier to read code if we check for flow->unmasked_key here. >> ovs_flow_cmp_unmasked_key() has assert on ufid anyways. > > With the change to put UFID/unmasked key in the same struct, there > will be no such pointer to check, only ufid_len. > right, Lets keep the check for ufid_len. > However, we could shift this check at the start of the function instead. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
On 9 December 2014 at 22:11, Pravin Shelar wrote: > On Tue, Dec 9, 2014 at 4:25 PM, Joe Stringer wrote: >> On 9 December 2014 at 10:32, Pravin Shelar wrote: >>> On Tue, Dec 2, 2014 at 6:56 PM, Joe Stringer wrote: @@ -424,10 +475,9 @@ static struct sw_flow *masked_flow_lookup(struct table_instance *ti, ovs_flow_mask_key(&masked_key, unmasked, mask); hash = flow_hash(&masked_key, key_start, key_end); head = find_bucket(ti, hash); - hlist_for_each_entry_rcu(flow, head, hash_node[ti->node_ver]) { - if (flow->mask == mask && flow->hash == hash && - flow_cmp_masked_key(flow, &masked_key, - key_start, key_end)) + hlist_for_each_entry_rcu(flow, head, flow_hash.node[ti->node_ver]) { + if (flow->mask == mask && flow->flow_hash.hash == hash && + flow_cmp_masked_key(flow, &masked_key, key_start, key_end)) return flow; } return NULL; @@ -469,7 +519,40 @@ struct sw_flow *ovs_flow_tbl_lookup_exact(struct flow_table *tbl, /* Always called under ovs-mutex. */ list_for_each_entry(mask, &tbl->mask_list, list) { flow = masked_flow_lookup(ti, match->key, mask); - if (flow && ovs_flow_cmp_unmasked_key(flow, match)) /* Found */ + if (flow && !flow->ufid && >>> why not NULL check for flow->unmasked_key here rather than ufid? >> >> In this version, I tried to consistently use flow->ufid as the switch >> for whether UFID exists or not. In the next version, this statement >> would refer to flow->id->ufid_len. >> >> The current approach means that ovs_flow_tbl_lookup_exact() is really >> ovs_flow_tbl_lookup_unmasked_key(). Do you think this should remain >> specific to unmasked key or should it be made to check that the >> identifier (ufid OR unmasked key) is the same? > > It is easier to read code if we check for flow->unmasked_key here. > ovs_flow_cmp_unmasked_key() has assert on ufid anyways. With the change to put UFID/unmasked key in the same struct, there will be no such pointer to check, only ufid_len. However, we could shift this check at the start of the function instead. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
On Tue, Dec 9, 2014 at 4:25 PM, Joe Stringer wrote: > On 9 December 2014 at 10:32, Pravin Shelar wrote: >> On Tue, Dec 2, 2014 at 6:56 PM, Joe Stringer wrote: >>> @@ -662,11 +664,18 @@ static void get_dp_stats(const struct datapath *dp, >>> struct ovs_dp_stats *stats, >>> } >>> } >>> + error = ovs_nla_copy_ufid(a[OVS_FLOW_ATTR_UFID], &ufid, log); >>> + if (error) >>> + return error; >>> + if (a[OVS_FLOW_ATTR_KEY]) { >>> + ovs_match_init(&match, &key, &mask); >>> + error = ovs_nla_get_match(&match, a[OVS_FLOW_ATTR_KEY], >>> + a[OVS_FLOW_ATTR_MASK], log); >>> + } else if (!ufid) { >>> OVS_NLERR(log, "Flow key attribute not present in set >>> flow."); >>> - goto error; >>> + error = -EINVAL; >>> } >>> - >>> - ovs_match_init(&match, &key, &mask); >>> - error = ovs_nla_get_match(&match, a[OVS_FLOW_ATTR_KEY], >>> - a[OVS_FLOW_ATTR_MASK], log); >>> if (error) >>> goto error; >>> >>> - /* Validate actions. */ >>> - if (a[OVS_FLOW_ATTR_ACTIONS]) { >>> - acts = get_flow_actions(a[OVS_FLOW_ATTR_ACTIONS], &key, >>> &mask, >>> - log); >>> - if (IS_ERR(acts)) { >>> - error = PTR_ERR(acts); >>> - goto error; >>> - } >>> - >>> - /* Can allocate before locking if have acts. */ >>> - reply = ovs_flow_cmd_alloc_info(acts, info, false); >>> - if (IS_ERR(reply)) { >>> - error = PTR_ERR(reply); >>> - goto err_kfree_acts; >>> - } >>> - } >>> - >> Why are you moving this action validation under ovs-lock? > > The thought was that flow_cmd_set may receive UFID and not key/mask. > One could imagine a command that sends a UFID and actions, telling OVS > kmod to update just the actions. Masked key is required for > ovs_nla_copy_actions(), so in this case a lookup would be required to > get a masked key. > > Perhaps the better alternative for the moment is to still require flow > key and mask for this command (just as we do for flow_cmd_new). That > would simplify this change greatly, and doesn't affect current OVS > userspace. > sounds good. >>> @@ -1194,9 +1254,18 @@ unlock: >>> >>> static int ovs_flow_cmd_dump(struct sk_buff *skb, struct netlink_callback >>> *cb) >>> { >>> + struct nlattr *a[__OVS_FLOW_ATTR_MAX]; >>> struct ovs_header *ovs_header = genlmsg_data(nlmsg_data(cb->nlh)); >>> struct table_instance *ti; >>> struct datapath *dp; >>> + u32 ufid_flags; >>> + int err; >>> + >>> + err = nlmsg_parse(cb->nlh, GENL_HDRLEN + >>> dp_flow_genl_family.hdrsize, >>> + a, dp_flow_genl_family.maxattr, flow_policy); >> >> Can you add genl helper function for this? > > OK. > >>> @@ -1235,6 +1304,8 @@ static const struct nla_policy >>> flow_policy[OVS_FLOW_ATTR_MAX + 1] = { >>> [OVS_FLOW_ATTR_ACTIONS] = { .type = NLA_NESTED }, >>> [OVS_FLOW_ATTR_CLEAR] = { .type = NLA_FLAG }, >>> [OVS_FLOW_ATTR_PROBE] = { .type = NLA_FLAG }, >>> + [OVS_FLOW_ATTR_UFID] = { .type = NLA_UNSPEC }, >>> + [OVS_FLOW_ATTR_UFID_FLAGS] = { .type = NLA_U32 }, >>> }; >>> >>> static const struct genl_ops dp_flow_genl_ops[] = { >>> diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h >>> index a8b30f3..7f31dbf 100644 >>> --- a/net/openvswitch/flow.h >>> +++ b/net/openvswitch/flow.h >>> @@ -197,6 +197,13 @@ struct sw_flow_match { >>> struct sw_flow_mask *mask; >>> }; >>> >>> +#define MAX_UFID_LENGTH 256 >>> + >> For now we can limit this to 128 bits. > > Is there a reason beyond trying to avoid the warning in flow_cmd_set()? > I suppose that its purpose as an identifier means that it's unlikely to > need to be much bigger in future (indeed, the larger it gets, the more > it would trade off the performance gains from using it). > I am also not sure why would we need ID larger than 128 bit. In such unlikely scenario I think we can increase it later if we need it. >>> @@ -213,13 +220,16 @@ struct flow_stats { >>> >>> struct sw_flow { >>> struct rcu_head rcu; >>> - struct hlist_node hash_node[2]; >>> - u32 hash; >>> + struct { >>> + struct hlist_node node[2]; >>> + u32 hash; >>> + } flow_hash, ufid_hash; >> I am not sure about _hash suffix here, Can you explain it? I think >> _table is better. > > Agreed, table is better. > >>> int stats_last_writer; /* NUMA-node id of the last writer >>> on >>> * 'stats[0]'. >>> */ >>> struct sw_flow_key key; >>> - struct sw_flow_key unmasked_key; >>> + stru
Re: [ovs-dev] [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
On 9 December 2014 at 10:32, Pravin Shelar wrote: > On Tue, Dec 2, 2014 at 6:56 PM, Joe Stringer wrote: >> @@ -662,11 +664,18 @@ static void get_dp_stats(const struct datapath *dp, >> struct ovs_dp_stats *stats, >> } >> } >> >> -static size_t ovs_flow_cmd_msg_size(const struct sw_flow_actions *acts) >> +static size_t ovs_flow_cmd_msg_size(const struct sw_flow_actions *acts, >> + const struct sw_flow_id *sfid) >> { >> + size_t sfid_len = 0; >> + >> + if (sfid && sfid->ufid_len) >> + sfid_len = nla_total_size(sfid->ufid_len); >> + > Can you also use ufid_flags to determine exact msg size? Yeah, that should be straightforward. >> @@ -849,13 +876,30 @@ static int ovs_flow_cmd_new(struct sk_buff *skb, >> struct genl_info *info) >> } >> >> /* Extract key. */ >> - ovs_match_init(&match, &new_flow->unmasked_key, &mask); >> + ovs_match_init(&match, &key, &mask); >> error = ovs_nla_get_match(&match, a[OVS_FLOW_ATTR_KEY], >> a[OVS_FLOW_ATTR_MASK], log); >> if (error) >> goto err_kfree_flow; >> >> - ovs_flow_mask_key(&new_flow->key, &new_flow->unmasked_key, &mask); >> + ovs_flow_mask_key(&new_flow->key, &key, &mask); >> + >> + /* Extract flow id. */ >> + error = ovs_nla_copy_ufid(a[OVS_FLOW_ATTR_UFID], &new_flow->ufid, >> log); >> + if (error) >> + goto err_kfree_flow; > > Returning zero in case of no UFID is strange. Can you check for UFID > attribute and then copy ufid unconditionally? Right, along with the changes I'll make to integrating unmasked_key and UFID this should collapse into a single call to ovs_nla_copy_identifier() which will handle both cases. >> @@ -877,8 +921,12 @@ static int ovs_flow_cmd_new(struct sk_buff *skb, struct >> genl_info *info) >> error = -ENODEV; >> goto err_unlock_ovs; >> } >> + >> /* Check if this is a duplicate flow */ >> - flow = ovs_flow_tbl_lookup(&dp->table, &new_flow->unmasked_key); >> + if (new_flow->ufid) >> + flow = ovs_flow_tbl_lookup_ufid(&dp->table, new_flow->ufid); >> + if (!flow) >> + flow = ovs_flow_tbl_lookup(&dp->table, &new_flow->key); > > Need tight checking, for example what if flow with UFID does not exist > in UFID table but it exist in flow-table? This can complicate > flow-update case where we can not assume UFID of new and old flow is > same. OK, I overlooked this for the UFID case. The non-UFID case does an exact lookup later in the function, we could add a check in the UFID case to compare the masked keys and return an error if they are unequal. >> @@ -980,45 +1032,34 @@ static int ovs_flow_cmd_set(struct sk_buff *skb, >> struct genl_info *info) >> struct nlattr **a = info->attrs; >> struct ovs_header *ovs_header = info->userhdr; >> struct sw_flow_key key; >> - struct sw_flow *flow; >> + struct sw_flow *flow = NULL; >> struct sw_flow_mask mask; >> struct sk_buff *reply = NULL; >> struct datapath *dp; >> struct sw_flow_actions *old_acts = NULL, *acts = NULL; >> struct sw_flow_match match; >> + struct sw_flow_id *ufid; >> + u32 ufid_flags = ovs_nla_get_ufid_flags(a[OVS_FLOW_ATTR_UFID_FLAGS]); >> int error; >> bool log = !a[OVS_FLOW_ATTR_PROBE]; >> >> - /* Extract key. */ >> - error = -EINVAL; >> - if (!a[OVS_FLOW_ATTR_KEY]) { >> + /* Extract identifier. Take a copy to avoid "Wframe-larger-than=1024" >> +* warning. >> +*/ > What if we limit the implementation of UFID to max 128 bit, does it > still gives you the warning? It will if we still use struct sw_flow_id, when we combine UFID+unmasked key. Possibly not with just a 128bit array. I'll look into it. >> + error = ovs_nla_copy_ufid(a[OVS_FLOW_ATTR_UFID], &ufid, log); >> + if (error) >> + return error; >> + if (a[OVS_FLOW_ATTR_KEY]) { >> + ovs_match_init(&match, &key, &mask); >> + error = ovs_nla_get_match(&match, a[OVS_FLOW_ATTR_KEY], >> + a[OVS_FLOW_ATTR_MASK], log); >> + } else if (!ufid) { >> OVS_NLERR(log, "Flow key attribute not present in set >> flow."); >> - goto error; >> + error = -EINVAL; >> } >> - >> - ovs_match_init(&match, &key, &mask); >> - error = ovs_nla_get_match(&match, a[OVS_FLOW_ATTR_KEY], >> - a[OVS_FLOW_ATTR_MASK], log); >> if (error) >> goto error; >> >> - /* Validate actions. */ >> - if (a[OVS_FLOW_ATTR_ACTIONS]) { >> - acts = get_flow_actions(a[OVS_FLOW_ATTR_ACTIONS], &key, >> &mask, >> - log); >> - if (IS_ERR(acts)) { >> -
Re: [ovs-dev] [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
Please do not quote an entire patch just to add some simple feedback or signoff/ack. That means someone has to scroll past the entire patch in patchwork or the mailing list archives, unnecessarily. This is one of my largest pet peeves, please do not do this. Thanks. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
On Tue, Dec 2, 2014 at 6:56 PM, Joe Stringer wrote: > Previously, flows were manipulated by userspace specifying a full, > unmasked flow key. This adds significant burden onto flow > serialization/deserialization, particularly when dumping flows. > > This patch adds an alternative way to refer to flows using a > variable-length "unique flow identifier" (UFID). At flow setup time, > userspace may specify a UFID for a flow, which is stored with the flow > and inserted into a separate table for lookup, in addition to the > standard flow table. Flows created using a UFID must be fetched or > deleted using the UFID. > > All flow dump operations may now be made more terse with OVS_UFID_F_* > flags. For example, the OVS_UFID_F_OMIT_KEY flag allows responses to > omit the flow key from a datapath operation if the flow has a > corresponding UFID. This significantly reduces the time spent assembling > and transacting netlink messages. With all OVS_UFID_F_OMIT_* flags > enabled, the datapath only returns the UFID and statistics for each flow > during flow dump, increasing ovs-vswitchd revalidator performance by up > to 50%. > > Signed-off-by: Joe Stringer Thanks for updating patch against net-next. > --- > v11: Separate UFID and unmasked key from sw_flow. > Modify interface to remove nested UFID attributes. > Only allow UFIDs between 1-256 octets. > Move UFID nla fetch helpers to flow_netlink.h. > Perform complete nlmsg_parsing in ovs_flow_cmd_dump(). > Check UFID table for flows with duplicate UFID at flow setup. > Tidy up mask/key/ufid insertion into flow_table. > Rebase. > v10: Ignore flow_key in requests if UFID is specified. > Only allow UFID flows to be indexed by UFID. > Only allow non-UFID flows to be indexed by unmasked flow key. > Unite the unmasked_key and ufid+ufid_hash in 'struct sw_flow'. > Don't periodically rehash the UFID table. > Resize the UFID table independently from the flow table. > Modify table_destroy() to iterate once and delete from both tables. > Fix UFID memory leak in flow_free(). > Remove kernel-only UFIDs for non-UFID cases. > Rename "OVS_UFID_F_SKIP_*" -> "OVS_UFID_F_OMIT_*" > Update documentation. > Rebase. > 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. > --- > Documentation/networking/openvswitch.txt | 13 ++ > include/uapi/linux/openvswitch.h | 20 +++ > net/openvswitch/datapath.c | 241 > +++--- > net/openvswitch/flow.h | 16 +- > net/openvswitch/flow_netlink.c | 63 +++- > net/openvswitch/flow_netlink.h |4 + > net/openvswitch/flow_table.c | 204 +++-- > net/openvswitch/flow_table.h |7 + > 8 files changed, 437 insertions(+), 131 deletions(-) > > diff --git a/Documentation/networking/openvswitch.txt > b/Documentation/networking/openvswitch.txt > index 37c20ee..b3b9ac6 100644 > --- a/Documentation/networking/openvswitch.txt > +++ b/Documentation/networking/openvswitch.txt > @@ -131,6 +131,19 @@ performs best-effort detection of overlapping wildcarded > flows and may reject > some but not all of them. However, this behavior may change in future > versions. > > > +Unique flow identifiers > +--- > + > +An alternative to using the original match portion of a key as the handle for > +flow identification is a unique flow identifier, or "UFID". UFIDs are > optional > +for both the kernel and user space program. > + > +User space programs that support UFID are expected to provide it during flow > +setup in addition to the flow, then refer to the flow using the UFID for all > +future operations. The kernel is not required to index flows by the original > +flow key if a UFID is specified. > + > + > Basic rule for evolving flow keys > - > > diff --git a/include/uapi/linux/openvswitch.h > b/include/uapi/linux/openvswitch.h > index 3a6dcaa..80db129 100644 > --- a/include/uapi/linux/openvswitch.h > +++ b/include/uapi/linux/openvswitch.h > @@ -444,6 +444,14 @@ struct ovs_key_nd { > * a wildcarded match. Omitting attribute is treated as wildcarding all > * corresponding fields. Optional for all requests. If not present, > * all flow key bits are exact match bits. > + * @OVS_FLOW_ATTR_UFID: A valu
Re: [ovs-dev] [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
On 3 December 2014 at 11:45, Pravin Shelar wrote: > On Wed, Dec 3, 2014 at 10:47 AM, Joe Stringer wrote: >> I forgot to mention that this is the first post based against net-next. >> >> On 2 December 2014 at 18:56, Joe Stringer wrote: >>>>>> diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h >>> index a8b30f3..7f31dbf 100644 >>> --- a/net/openvswitch/flow.h >>> +++ b/net/openvswitch/flow.h >>> @@ -197,6 +197,13 @@ struct sw_flow_match { >>> struct sw_flow_mask *mask; >>> }; >>> >>> +#define MAX_UFID_LENGTH 256 >>> + >>> +struct sw_flow_id { >>> + u32 ufid_len; >>> + u32 ufid[MAX_UFID_LENGTH / 4]; >>> +}; >>> + >>> struct sw_flow_actions { >>> struct rcu_head rcu; >>> u32 actions_len; >> >> Pravin, I changed the 'struct sw_flow_id' to the above after feedback >> from the previous round, but it doesn't seem quite right. Is this what >> you meant? Given that current ovs-vswitchd userspace only generates >> 128bit UFIDs, it seems wasteful to be allocating so much for this. Did >> you have in mind for this to be united with the unmasked_key? > > I am fine with 128bits of ufid, we can extend it later if we need it. > But what do you mean by united unmasked key? Can you define the struct > here? What I mean, is that we could define sw_flow_id as: +struct sw_flow_id { + u32 ufid_len; + u32 ufid[]; +}; ...and just allocate sizeof(struct sw_flow_id) + nla_len(ufid_nlattr), rather than always allocating a 260B structure. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
On Wed, Dec 3, 2014 at 10:47 AM, Joe Stringer wrote: > I forgot to mention that this is the first post based against net-next. > > On 2 December 2014 at 18:56, Joe Stringer wrote: >>>> diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h >> index a8b30f3..7f31dbf 100644 >> --- a/net/openvswitch/flow.h >> +++ b/net/openvswitch/flow.h >> @@ -197,6 +197,13 @@ struct sw_flow_match { >> struct sw_flow_mask *mask; >> }; >> >> +#define MAX_UFID_LENGTH 256 >> + >> +struct sw_flow_id { >> + u32 ufid_len; >> + u32 ufid[MAX_UFID_LENGTH / 4]; >> +}; >> + >> struct sw_flow_actions { >> struct rcu_head rcu; >> u32 actions_len; > > Pravin, I changed the 'struct sw_flow_id' to the above after feedback > from the previous round, but it doesn't seem quite right. Is this what > you meant? Given that current ovs-vswitchd userspace only generates > 128bit UFIDs, it seems wasteful to be allocating so much for this. Did > you have in mind for this to be united with the unmasked_key? I am fine with 128bits of ufid, we can extend it later if we need it. But what do you mean by united unmasked key? Can you define the struct here? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
I forgot to mention that this is the first post based against net-next. On 2 December 2014 at 18:56, Joe Stringer wrote: >> diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h > index a8b30f3..7f31dbf 100644 > --- a/net/openvswitch/flow.h > +++ b/net/openvswitch/flow.h > @@ -197,6 +197,13 @@ struct sw_flow_match { > struct sw_flow_mask *mask; > }; > > +#define MAX_UFID_LENGTH 256 > + > +struct sw_flow_id { > + u32 ufid_len; > + u32 ufid[MAX_UFID_LENGTH / 4]; > +}; > + > struct sw_flow_actions { > struct rcu_head rcu; > u32 actions_len; Pravin, I changed the 'struct sw_flow_id' to the above after feedback from the previous round, but it doesn't seem quite right. Is this what you meant? Given that current ovs-vswitchd userspace only generates 128bit UFIDs, it seems wasteful to be allocating so much for this. Did you have in mind for this to be united with the unmasked_key? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
Previously, flows were manipulated by userspace specifying a full, unmasked flow key. This adds significant burden onto flow serialization/deserialization, particularly when dumping flows. This patch adds an alternative way to refer to flows using a variable-length "unique flow identifier" (UFID). At flow setup time, userspace may specify a UFID for a flow, which is stored with the flow and inserted into a separate table for lookup, in addition to the standard flow table. Flows created using a UFID must be fetched or deleted using the UFID. All flow dump operations may now be made more terse with OVS_UFID_F_* flags. For example, the OVS_UFID_F_OMIT_KEY flag allows responses to omit the flow key from a datapath operation if the flow has a corresponding UFID. This significantly reduces the time spent assembling and transacting netlink messages. With all OVS_UFID_F_OMIT_* flags enabled, the datapath only returns the UFID and statistics for each flow during flow dump, increasing ovs-vswitchd revalidator performance by up to 50%. Signed-off-by: Joe Stringer --- v11: Separate UFID and unmasked key from sw_flow. Modify interface to remove nested UFID attributes. Only allow UFIDs between 1-256 octets. Move UFID nla fetch helpers to flow_netlink.h. Perform complete nlmsg_parsing in ovs_flow_cmd_dump(). Check UFID table for flows with duplicate UFID at flow setup. Tidy up mask/key/ufid insertion into flow_table. Rebase. v10: Ignore flow_key in requests if UFID is specified. Only allow UFID flows to be indexed by UFID. Only allow non-UFID flows to be indexed by unmasked flow key. Unite the unmasked_key and ufid+ufid_hash in 'struct sw_flow'. Don't periodically rehash the UFID table. Resize the UFID table independently from the flow table. Modify table_destroy() to iterate once and delete from both tables. Fix UFID memory leak in flow_free(). Remove kernel-only UFIDs for non-UFID cases. Rename "OVS_UFID_F_SKIP_*" -> "OVS_UFID_F_OMIT_*" Update documentation. Rebase. 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. --- Documentation/networking/openvswitch.txt | 13 ++ include/uapi/linux/openvswitch.h | 20 +++ net/openvswitch/datapath.c | 241 +++--- net/openvswitch/flow.h | 16 +- net/openvswitch/flow_netlink.c | 63 +++- net/openvswitch/flow_netlink.h |4 + net/openvswitch/flow_table.c | 204 +++-- net/openvswitch/flow_table.h |7 + 8 files changed, 437 insertions(+), 131 deletions(-) diff --git a/Documentation/networking/openvswitch.txt b/Documentation/networking/openvswitch.txt index 37c20ee..b3b9ac6 100644 --- a/Documentation/networking/openvswitch.txt +++ b/Documentation/networking/openvswitch.txt @@ -131,6 +131,19 @@ performs best-effort detection of overlapping wildcarded flows and may reject some but not all of them. However, this behavior may change in future versions. +Unique flow identifiers +--- + +An alternative to using the original match portion of a key as the handle for +flow identification is a unique flow identifier, or "UFID". UFIDs are optional +for both the kernel and user space program. + +User space programs that support UFID are expected to provide it during flow +setup in addition to the flow, then refer to the flow using the UFID for all +future operations. The kernel is not required to index flows by the original +flow key if a UFID is specified. + + Basic rule for evolving flow keys - diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h index 3a6dcaa..80db129 100644 --- a/include/uapi/linux/openvswitch.h +++ b/include/uapi/linux/openvswitch.h @@ -444,6 +444,14 @@ struct ovs_key_nd { * a wildcarded match. Omitting attribute is treated as wildcarding all * corresponding fields. Optional for all requests. If not present, * all flow key bits are exact match bits. + * @OVS_FLOW_ATTR_UFID: A value between 1-256 octets specifying a unique + * identifier for the flow. Causes the flow to be indexed by this value rather + * than the value of the %OVS_FLOW_ATTR_KEY attribute. Optional for all + * requests. Present in notifications if the flow was created with this + * attribute. + * @OVS_FLOW_ATTR_UFID_F