From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ferruh.yigit@intel.com> Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 7A0F05A6A for <dev@dpdk.org>; Tue, 9 May 2017 15:37:48 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP; 09 May 2017 06:37:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,314,1491289200"; d="scan'208";a="85328836" 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:37:46 -0700 To: =?UTF-8?Q?Morten_Br=c3=b8rup?= <mb@smartsharesystems.com>, "Mcnamara, John" <john.mcnamara@intel.com>, dev@dpdk.org Cc: "Tahhan, Maryam" <maryam.tahhan@intel.com>, =?UTF-8?Q?Ga=c3=abtan_Rivet?= <gaetan.rivet@6wind.com> References: <20170420185448.19162-1-ferruh.yigit@intel.com> <20170421103813.GH14914@bidouze.vm.6wind.com> <B27915DBBA3421428155699D51E4CFE2332C69AC@IRSMSX103.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC359EAFAA@smartserver.smartshare.dk> From: Ferruh Yigit <ferruh.yigit@intel.com> Message-ID: <895d3523-6d66-d268-4d0e-37d42df02c5a@intel.com> Date: Tue, 9 May 2017 14:37:46 +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: <98CBD80474FA8B44BF855DF32C47DC359EAFAA@smartserver.smartshare.dk> 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Tue, 09 May 2017 13:37:50 -0000 On 5/6/2017 3:04 PM, Morten Brørup wrote: > Carthago delenda est: Again with the callbacks... why not just let the application call the library's processing functions where appropriate. The hook+callback design pattern tends to impose a specific framework (or order of execution) on the DPDK user, rather than just being a stand-alone library offering some functions. DPDK is not a stack; and one of the reasons we are moving our firmware away from Linux is to avoid being enforced a specific order of processing the packets (through a whole bunch of hooks everywhere in the stack). > I agree on callbacks usage, but I can't see the other option for this case. This is for additional functionality to get flow information, while packet processing happens. So with don't want this functionality to be available always or to be part of the processing. And this data requires each packet to be processed, what can be the "library's processing function" alternative can be? > Maybe I missed the point of this library, so bear with me if my example is stupid: > > Consider a NAT router application. Does this library support processing ingress packets in the outside->inside direction after they have been processed by the NAT engine? Or how about IP fragments after passing the reassembly engine? Implementation is not there, we have packet information, and I guess with more processing of packets, the proper flow information can be created for various cases. But my concern is if this should be in DPDK? I was thinking to provide API to the application to give the flow information with a specific key, and rest of the processing can be done in upper layer, who calls these APIs. > > > Generally, a generic flow processing library would be great; but such a library would need to support flow processing applications, not just byte counting. Four key functions would be required: 1. Identify which flow a packet belongs to (or "not found"), 2. Create a flow, 3. Destroy a flow, and 4. Iterate through flows (e.g. for aging or listing purposes). Agreed, and where should this be? Part of DPDK, or DPDK providing some APIs to enable this kind of library on top of DPDK? > > > Med venlig hilsen / kind regards > - Morten Brørup > > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Mcnamara, John >> Sent: Wednesday, May 3, 2017 11:16 AM >> To: dev@dpdk.org >> Cc: Tahhan, Maryam; Gaëtan Rivet; Yigit, Ferruh >> Subject: Re: [dpdk-dev] [RFC 17.08] Flow classification library >> >> >> >>> -----Original Message----- >>> From: Gaëtan Rivet [mailto:gaetan.rivet@6wind.com] >>> Sent: Friday, April 21, 2017 11:38 AM >>> To: Yigit, Ferruh <ferruh.yigit@intel.com> >>> Cc: dev@dpdk.org; Mcnamara, John <john.mcnamara@intel.com>; Tahhan, >>> Maryam <maryam.tahhan@intel.com> >>> Subject: Re: [dpdk-dev] [RFC 17.08] Flow classification library >>> >> >> >> Any other opinions on this proposal? >> >> (Original email: http://dpdk.org/ml/archives/dev/2017-April/064443.html) >> >> John >