From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 816E82BB5 for ; Wed, 24 Feb 2016 16:15:02 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 24 Feb 2016 07:15:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,494,1449561600"; d="scan'208";a="658584442" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by FMSMGA003.fm.intel.com with ESMTP; 24 Feb 2016 07:15:00 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.237]) by IRSMSX154.ger.corp.intel.com ([169.254.12.174]) with mapi id 14.03.0248.002; Wed, 24 Feb 2016 15:14:58 +0000 From: "Ananyev, Konstantin" To: "Thomas Monjalon (thomas.monjalon@6wind.com)" Thread-Topic: [dpdk-dev] [PATCH] eal: Initial implementation of PQoS EAL extension Thread-Index: AdFvFfJvibLMge66TW6nKpLvfdW8mw== Date: Wed, 24 Feb 2016 15:14:58 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836B0AD59@irsmsx105.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODRjNzhjYTAtOWJkOS00Yjg5LTk0NDQtMjY3MjA2ZDRiMTBiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InZrejVzZjhEQ3U2WUpSdm9uOGdnd0VIeGRydlpRS0RWa0x2eEhVVEs4U2M9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] eal: Initial implementation of PQoS EAL extension X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 15:15:03 -0000 > > > 2016-02-24 10:22, Ananyev, Konstantin: > > > > > > > > > -----Original Message----- > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richar= dson > > > > > Sent: Wednesday, February 24, 2016 10:10 AM > > > > > To: Thomas Monjalon > > > > > Cc: dev@dpdk.org; Kantecki, Tomasz > > > > > Subject: Re: [dpdk-dev] [PATCH] eal: Initial implementation of PQ= oS EAL extension > > > > > > > > > > On Wed, Feb 24, 2016 at 09:24:33AM +0100, Thomas Monjalon wrote: > > > > > > 2016-02-23 23:03, Kantecki, Tomasz: > > > > > > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > > > > > If there is nothing specific in DPDK for PQos, why writing = an example in > > > > > > > > DPDK? > > > > > > > The example makes it much easier to use the technology with D= PDK. > > > > > > > > > > > > > > > Maybe the example should be better in the library itself. > > > > > > > The library in question (https://github.com/01org/intel-cmt-c= at) has a couple of examples but none of them refers to > DPDK. > > > > > > > > > > > > > > > I suggest to mention the library in > > > > > > > > doc/guides/linux_gsg/nic_perf_intel_platform.rst > > > > > > > Ok it can be added to this document. Does it imply -1 for the= sample code idea? > > > > > > > > > > > > I may be wrong but I have the feeling the example is more about= PQoS than DPDK. > > > > > > So yes, I would vote -1. > > > > > > > > > > > Well, the intersection of DPDK and PQoS is what the example is re= ally all about, > > > > > and as such it is relevant to both DPDK and the library itself. P= latform QoS > > > > > can be of great use to packet processing applications for helping= to ensure that > > > > > the app gets the resources it needed - especially in a virtualise= d world - and > > > > > so we believe that having an example in DPDK showing how to use P= QoS with DPDK > > > > > is well worthwhile having. It's more effective than a simple doc = update in > > > > > raising awareness of the existence of the feature, and also provi= des for DPDK > > > > > users a readily available app for the user to start playing with = to evaluate > > > > > PQoS for their own use-cases. > > > > > > > > +1 > > > > I also think it is a good thing to have. > > > > Again user don't have to trust the whitepapers - instead he can run= the app > > > > and measure performance gain on his particular platform. > > > > > > I totally agree the example is good to have. > > > Konstantin, are you thinking it must be hosted in the PQoS lib reposi= tory? > > > > Personally I prefer it to be part of dpdk samples. > > DPDK IO code path is a bit different from what the 'classical' user app= usually does - > > a lot of polling, avoid system calls, etc. > > Also it would probably have much better visibility here. > > Again, as Bruce already mentioned, we have QAT & TAP samples, why we c= an't have PQoS too. >=20 > Indeed the DPDK policies are really flexible. > How would you suggest to decide which examples can enter in DPDK? That's a good question, for which I don't have an exact answer. Probably a good opportunity for the TB to show itself :) My input would be - to justify new sample for dpdk+third-party-lib it has t= o demonstrate one of: a) clear performance gain for the existing dpdk application, i.e under scenario X with library Y dpdk app Z shows N% better performance. (PQos example). b) how to integrate dpdk based app with some well-known and widely used tec= hnology. (tap example, using fuse to implement vhost example). c) How to expand packet processing with the functionality that is not part = of dpdk project.=20 So yes, if tomorrow someone will come up with example that does packet comp= ression, or encryption or DPI using some third party library, I think we at least ha= ve to consider to include it inside dpdk.org/examples. As a restriction I would put that the example has to be relatively small a= nd simple=20 and demonstrate particular feature usage.=20 Plus I think that this third-party library has to be freely available and o= pen-sourced.=20 Konstantin > Examples: what about a zip compression in the forwarding plane? > What about a VM2VM failover synchronization?