Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752013AbaLCVCz (ORCPT ); Wed, 3 Dec 2014 16:02:55 -0500 Received: from na6sys009bog026.obsmtp.com ([74.125.150.92]:58461 "HELO na6sys009bog026.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1750893AbaLCVCx (ORCPT ); Wed, 3 Dec 2014 16:02:53 -0500 MIME-Version: 1.0 In-Reply-To: References: <1417575363-13770-1-git-send-email-joestringer@nicira.com> <1417575363-13770-2-git-send-email-joestringer@nicira.com> From: Joe Stringer Date: Wed, 3 Dec 2014 13:02:31 -0800 Message-ID: Subject: Re: [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs. To: Pravin Shelar Cc: Linux Kernel , "dev@openvswitch.org" , Linux Netdev List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: >>> <....snip...> >>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/