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 2F4225A6A for ; Tue, 9 May 2017 15:26:37 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2017 06:26:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,314,1491289200"; d="scan'208";a="85326027" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.81]) ([10.237.220.81]) by orsmga004.jf.intel.com with ESMTP; 09 May 2017 06:26:34 -0700 To: =?UTF-8?Q?Ga=c3=abtan_Rivet?= Cc: dev@dpdk.org, John McNamara , Maryam Tahhan References: <20170420185448.19162-1-ferruh.yigit@intel.com> <20170421103813.GH14914@bidouze.vm.6wind.com> From: Ferruh Yigit Message-ID: Date: Tue, 9 May 2017 14:26:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170421103813.GH14914@bidouze.vm.6wind.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [RFC 17.08] Flow classification library 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: Tue, 09 May 2017 13:26:38 -0000 On 4/21/2017 11:38 AM, Gaëtan Rivet wrote: > Hi Ferruh, > > On Thu, Apr 20, 2017 at 07:54:47PM +0100, Ferruh Yigit wrote: >> DPDK works with packets, but some network administration tools works based on >> flow information. >> >> This library is suggested to provide helper APIs to convert packet based >> information to the flow records. Library header file has more comments on >> how library works and provided APIs. >> >> Packets to flow conversion will cause performance drop, that is why this >> conversion can be enabled and disabled dynamically by application. >> >> Initial implementation in mind is to provide support for IPFIX metering process >> but library planned to be as generic as possible. And flow information provided >> by this library is missing to implement full IPFIX features, but this is planned >> to be initial step. >> > > In order to be generic, would it not be interesting to specify the flow > as a generic rte_flow_item list? Some specific IPFIX items are not > expressed currently in rte_flow (e.g. packet size), but they could be added. > > This library could consist in an rte_flow_item to IPFIX translation. Agreed, it would be better to be able to use rte_flow, but I am not sure if rte_flow will be enough for this case. rte_flow is to create flow rules in PMD level, but what this library aims to collect flow information, independent from if underlying PMD implemented rte_flow or not. So issues with using rte_flow for this use case: 1- It may not be implemented for all PMDs (including virtual ones). 2- It may conflict with other rte_flow rules created by user. 3- It may not gather all information required. > > The inverse approach could be used, but seems backward to me. It makes > more sense to support DPDK idioms and open them to standards by > proper APIs than including standards in internals and introduce > translation layers between DPDK components. > >> It is possible to define flow with various flow keys, but currently only one >> type of flow defined in the library, which is more generic, and it offloads >> fine grained flow analysis to the application. Library enables expanding for >> other flow types. >> > > I'm not sure I understand the purpose of this flow key, generic > is too general of a hint to define the possible cases. > > However, my intuition is that the flow type describe a filter to > restrict the flow classification to specific patterns instead of all > supported ones. Yes, that is the intention. User can define flow by key. And IPFIX supports many flow features, that is missing right now. > > This library thus resembles using the action RTE_FLOW_ACTION_TYPE_COUNT, then > retrieved using rte_flow_query_count. The rte_flow_item aggregated with > the rte_flow_query_count structure could be sufficient to derive IPFIX > meters? For counting, COUNT action looks like good candidate, it looks like it is hard to build flow classification functionality completely on top of rte_flow, but rte_flow can be used when appropriate like this case. > > An application could then use this data for its IPFIX support. > >> It will be more beneficial to shape this library to cover more use cases, please >> feel free to comment on possible other use case and desired functionalities. >> >> Thanks, >> ferruh >> >> cc: John McNamara >> cc: Maryam Tahhan >> >> Ferruh Yigit (1): >> flow_classify: add librte_flow_classify library >> >> config/common_base | 5 + >> doc/api/doxy-api-index.md | 1 + >> doc/api/doxy-api.conf | 1 + >> doc/guides/rel_notes/release_17_05.rst | 1 + >> lib/Makefile | 2 + >> lib/librte_flow_classify/Makefile | 50 +++++ >> lib/librte_flow_classify/rte_flow_classify.c | 34 ++++ >> lib/librte_flow_classify/rte_flow_classify.h | 202 +++++++++++++++++++++ >> .../rte_flow_classify_version.map | 10 + >> 9 files changed, 306 insertions(+) >> create mode 100644 lib/librte_flow_classify/Makefile >> create mode 100644 lib/librte_flow_classify/rte_flow_classify.c >> create mode 100644 lib/librte_flow_classify/rte_flow_classify.h >> create mode 100644 lib/librte_flow_classify/rte_flow_classify_version.map >> >> -- >> 2.9.3 >> >