From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 4130629CF for ; Fri, 6 Jan 2017 14:52:55 +0100 (CET) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP; 06 Jan 2017 05:52:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,324,1477983600"; d="scan'208";a="50231397" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.38]) ([10.237.220.38]) by fmsmga005.fm.intel.com with ESMTP; 06 Jan 2017 05:52:54 -0800 To: Adrien Mazarguil References: <025e66266f9baba7515ad4ba54a4a6addc9e2345.1483022600.git.nelio.laranjeiro@6wind.com> <2973bbd2-8db3-f9e4-da9a-359e399527b3@intel.com> <20170104184222.GI12822@6wind.com> Cc: Nelio Laranjeiro , dev@dpdk.org From: Ferruh Yigit Message-ID: <37389e42-030a-a36f-57bc-a7ef15a0ee66@intel.com> Date: Fri, 6 Jan 2017 13:52:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170104184222.GI12822@6wind.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v5 2/6] net/mlx5: support basic flow items and actions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 13:52:56 -0000 On 1/4/2017 6:42 PM, Adrien Mazarguil wrote: > Hi Ferruh, > > On Wed, Jan 04, 2017 at 05:49:46PM +0000, Ferruh Yigit wrote: >> Hi Nelio, >> >> A quick question. > > I'll reply since it's related to the API. > >> On 12/29/2016 3:15 PM, Nelio Laranjeiro wrote: >>> Introduce initial software for rte_flow rules. >>> >>> VLAN, VXLAN are still not supported. >>> >>> Signed-off-by: Nelio Laranjeiro >>> Acked-by: Adrien Mazarguil >> >> <...> >> >>> +static int >>> +priv_flow_validate(struct priv *priv, >>> + const struct rte_flow_attr *attr, >>> + const struct rte_flow_item items[], >>> + const struct rte_flow_action actions[], >>> + struct rte_flow_error *error, >>> + struct mlx5_flow *flow) >>> +{ >>> + const struct mlx5_flow_items *cur_item = mlx5_flow_items; >> >> <...> >> >>> + for (; items->type != RTE_FLOW_ITEM_TYPE_END; ++items) { >> <...> >>> + } >>> + for (; actions->type != RTE_FLOW_ACTION_TYPE_END; ++actions) { >> <...> >>> + } >> >> Is it guarantied in somewhere that items or actions terminated with >> TYPE_END? > > Yes, since it's now the only way to terminate items/actions lists [1][2]. > There used to be a "max" value in the original draft but it seemed redundant > and proved annoying to use, and was therefore dropped. > > END items/actions behave like a NUL terminator for C strings. They are > likewise defined with value 0 for convenience. At least it is good idea to set END values to 0, but still if user not set it, most probably this will crash the app. Although most probably this kind of error will be detected easily in development phase, still it would be nice to return an error instead of crashing when user provide wrong input. > >> And these fields are direct inputs from user. >> Is there a way to verify user provided values are with TYPE_END terminated? > > No, applications must check for its presence (they normally add it > themselves) before feeding these lists to PMDs. I think that's safe enough. > > Note the testpmd flow command does not allow entering a flow rule without > "end" tokens in both lists, there is no way around this restriction. > > [1] http://dpdk.org/doc/guides/prog_guide/rte_flow.html#matching-pattern > [2] http://dpdk.org/doc/guides/prog_guide/rte_flow.html#actions >