From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 9CC015F6E for ; Tue, 8 May 2018 12:16:24 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2018 03:16:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,377,1520924400"; d="scan'208";a="37694240" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga007.fm.intel.com with ESMTP; 08 May 2018 03:16:23 -0700 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 8 May 2018 11:16:22 +0100 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.150]) by irsmsx155.ger.corp.intel.com ([169.254.14.95]) with mapi id 14.03.0319.002; Tue, 8 May 2018 11:16:21 +0100 From: "De Lara Guarch, Pablo" To: "Chalupnik, KamilX" , "dev@dpdk.org" CC: "Mokhtar, Amr" Thread-Topic: [PATCH 09/13] bbdev: measure offload cost Thread-Index: AQHT3WMUWcfuwlx6rUmlijGuQJ9ESKQkUQ3ggAEnRwCAACINAP///UcAgAATd8A= Date: Tue, 8 May 2018 10:16:21 +0000 Message-ID: References: <20180426133008.12388-1-kamilx.chalupnik@intel.com> <20180426133008.12388-9-kamilx.chalupnik@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMWM4YzQyNTEtZjVhNy00MzQ2LTk5YTUtOGE1MTViOWYxNjA0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6InlsZWVqdkVrTDE1MEt2ZTB3VDIyM1NGZStiMzhQSFBoTDYrK29pazZmdDQ9In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 09/13] bbdev: measure offload cost 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, 08 May 2018 10:16:25 -0000 > -----Original Message----- > From: Chalupnik, KamilX > Sent: Tuesday, May 8, 2018 10:48 AM > To: De Lara Guarch, Pablo ; dev@dpdk.org > Cc: Mokhtar, Amr > Subject: RE: [PATCH 09/13] bbdev: measure offload cost >=20 > Hi Pablo, >=20 > > -----Original Message----- > > From: De Lara Guarch, Pablo > > Sent: Tuesday, May 8, 2018 11:08 AM > > To: Chalupnik, KamilX ; dev@dpdk.org > > Cc: Mokhtar, Amr > > Subject: RE: [PATCH 09/13] bbdev: measure offload cost > > > > Hi Kamil, > > > > > -----Original Message----- > > > From: Chalupnik, KamilX > > > Sent: Tuesday, May 8, 2018 8:56 AM > > > To: De Lara Guarch, Pablo ; > > > dev@dpdk.org > > > Cc: Mokhtar, Amr > > > Subject: RE: [PATCH 09/13] bbdev: measure offload cost > > > > > > > > > > > > > -----Original Message----- > > > > From: De Lara Guarch, Pablo > > > > Sent: Monday, May 7, 2018 3:29 PM > > > > To: Chalupnik, KamilX ; dev@dpdk.org > > > > Cc: Mokhtar, Amr > > > > Subject: RE: [PATCH 09/13] bbdev: measure offload cost > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Chalupnik, KamilX > > > > > Sent: Thursday, April 26, 2018 2:30 PM > > > > > To: dev@dpdk.org > > > > > Cc: Mokhtar, Amr ; De Lara Guarch, Pablo > > > > > ; Chalupnik, KamilX > > > > > > > > > > Subject: [PATCH 09/13] bbdev: measure offload cost > > > > > > > > > > > > > ... > > > > > > > > > --- a/lib/librte_bbdev/rte_bbdev.h > > > > > +++ b/lib/librte_bbdev/rte_bbdev.h > > > > > @@ -239,6 +239,10 @@ struct rte_bbdev_stats { > > > > > uint64_t enqueue_err_count; > > > > > /** Total error count on operations dequeued */ > > > > > uint64_t dequeue_err_count; > > > > > +#ifdef RTE_TEST_BBDEV > > > > > + /** It stores offload time. */ > > > > > > > > Just "offload time" is fine. > > > > > > > > > + uint64_t offload_time; > > > > > +#endif > > > > > > > > Again, I don't think it is a good idea to have this compilation che= ck. > > > > RTE_TEST_BBDEV is used to enable the compilation of the test app, > > > > so it shouldn't be used for anything else. > > > > Also, in DPDK, we are avoiding the usage of this conditionals to > > > > enable/disable pieces of code. > > > > > > > If you want to avoid the computation of this time, add a > > > > configuration option in bbdev configuration structure > > > > (rte_bbdev_queue_conf?), so the decision is made at runtime. > > > > > > Ok, but this 'offload_time' variable is used only for testing > > > purposes so we decided that it should exist only when test applicatio= n is > being built. > > > In case where we move the decision to runtime phase it may have bad > > > impact on driver performance because then each time we have to check > > > if > > 'offload_time' > > > has to be calculated or not. > > > > I understand the performance penalty. Anyway, if you go for build time > > check, you should have another option name. The test app option should > > not affect the code in a library/PMD. > > Also, this option should probably be disabled, to avoid the extra > > calculations unnecessarily. > > Lastly, I think it would be better to always have "offload_time" field > > in the structure, so remove the check there. > > >=20 > So should I create and use in driver new guard for 'offload_time' and add= it to > config/common_base (or set it in Makefile when RTE_TEST_BBDEV is set). Ar= e > you ok for such exception to the DPDK code guidelines in this case? I would leave "offload_time" always available in the structure, so its size= doesn't change depending on this option. It is better to avoid adding these options, but if we do it for perf reason= s (if it affects data path code), then at least it should be well designed, so there should be a separate opt= ion (either under TURBO_SW or BBDEV), and I think it should be disabled by default. The test app is enabled by default, so users most likely would have this en= abled without needing it, impacting performance. Therefore, I'd say it is better to avoid relating th= is to the test app. You can document that this option should be enabled if offload times are wa= nted (and maybe check in the test app if the compilation flag is set and show a = message to enable it if user is interested). >=20 > Best regards, > Kamil