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 92C791B117 for ; Wed, 5 Dec 2018 09:51:49 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2018 00:51:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,317,1539673200"; d="scan'208";a="98199316" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga006.jf.intel.com with ESMTP; 05 Dec 2018 00:51:48 -0800 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 5 Dec 2018 00:51:46 -0800 Received: from HASMSX109.ger.corp.intel.com (10.184.198.21) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 5 Dec 2018 00:51:46 -0800 Received: from hasmsx112.ger.corp.intel.com ([169.254.11.97]) by hasmsx109.ger.corp.intel.com ([169.254.3.164]) with mapi id 14.03.0415.000; Wed, 5 Dec 2018 10:51:43 +0200 From: "Jozwiak, TomaszX" To: "Verma, Shally" , "Trahe, Fiona" , "Daly, Lee" CC: "dev@dpdk.org" , "akhil.goyal@nxp.com" Thread-Topic: [dpdk-dev] [PATCH 2/3] app/compress-perf: add performance measurement Thread-Index: AQHUZJkxcIGln+39A0uVljPKIaOJxKUjgX3wgAAEmACAAB780P//8ysAgEUUV0CAAnxEAIAE/G6Q Date: Wed, 5 Dec 2018 08:51:42 +0000 Message-ID: References: <1538400427-20164-1-git-send-email-tomaszx.jozwiak@intel.com> <1538400427-20164-3-git-send-email-tomaszx.jozwiak@intel.com> <348A99DA5F5B7549AA880327E580B4358964F1CB@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B4358964F45C@IRSMSX101.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.103.104.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 2/3] app/compress-perf: add performance measurement 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: Wed, 05 Dec 2018 08:51:50 -0000 Hi Shally, > I don't think segsz is required to input then? Yes, this param. together with others like: input sz and max-num-segs-sgl gives possibility to find the best performance values set for each PMD, so = let's keep it. Br, Tomek > -----Original Message----- > From: Verma, Shally [mailto:Shally.Verma@cavium.com] > Sent: Sunday, December 2, 2018 7:40 AM > To: Jozwiak, TomaszX ; Trahe, Fiona > ; Daly, Lee > Cc: dev@dpdk.org; akhil.goyal@nxp.com > Subject: RE: [dpdk-dev] [PATCH 2/3] app/compress-perf: add performance > measurement >=20 > Ok. Then to keep it simple can we keep input sz and max-num-segs-sgl at > cmd line input. I don't think segsz is required to input then? >=20 > Thanks > Shally >=20 > >-----Original Message----- > >From: Jozwiak, TomaszX > >Sent: 30 November 2018 20:13 > >To: Verma, Shally ; Trahe, Fiona > >; Daly, Lee > >Cc: dev@dpdk.org; akhil.goyal@nxp.com > >Subject: RE: [dpdk-dev] [PATCH 2/3] app/compress-perf: add performance > >measurement > > > >External Email > > > >Hi Shally, > > > >I'm about of sending V5 of compression-perf tool. > > > >Our performance testing shows that the number of sgls in a chain can be = a > factor in the performance. > >So we want to keep this on the cmd line for the performance tool. > >There are alternatives, like setting the input size and segment size to > >get the num segments desired, but I prefer to have the option to specify > the num segments explicitly. > >We'll document that if the max-num-sgl-segs x seg_sz > input size then > >segments number in the chain will be lower ( to store all the > >data) > >As regards adding the max_nb_segments_per_sgl into the > >rte_compressdev_info struct we're investigating another workaround to > this limitation in QAT, so will leave this off the API unless some other = PMD > needs it. > >In the meantime we'll document the limitation in QAT. > > > >Please let me know your thoughts. > > > >-- > >Tomek > > > >> -----Original Message----- > >> From: Verma, Shally [mailto:Shally.Verma@cavium.com] > >> Sent: Wednesday, October 17, 2018 6:48 PM > >> To: Trahe, Fiona ; Daly, Lee > >> > >> Cc: Jozwiak, TomaszX ; dev@dpdk.org; > >> akhil.goyal@nxp.com > >> Subject: RE: [dpdk-dev] [PATCH 2/3] app/compress-perf: add > >> performance measurement > >> > >> > >> > >> >-----Original Message----- > >> >From: Trahe, Fiona > >> >Sent: 17 October 2018 22:15 > >> >To: Verma, Shally ; Daly, Lee > >> > > >> >Cc: Jozwiak, TomaszX ; dev@dpdk.org; > >> >akhil.goyal@nxp.com; Trahe, Fiona > >> >Subject: RE: [dpdk-dev] [PATCH 2/3] app/compress-perf: add > >> >performance measurement > >> > > >> >External Email > >> > > >> >> -----Original Message----- > >> >> From: Verma, Shally [mailto:Shally.Verma@cavium.com] > >> >> Sent: Wednesday, October 17, 2018 8:43 AM > >> >> To: Trahe, Fiona ; Daly, Lee > >> >> > >> >> Cc: Jozwiak, TomaszX ; dev@dpdk.org; > >> >> akhil.goyal@nxp.com > >> >> Subject: RE: [dpdk-dev] [PATCH 2/3] app/compress-perf: add > >> >> performance measurement > >> >> > >> >> > >> >> > >> >> >-----Original Message----- > >> >> >From: Trahe, Fiona > >> >> >Sent: 17 October 2018 20:04 > >> >> >To: Daly, Lee ; Verma, Shally > >> >> > > >> >> >Cc: Jozwiak, TomaszX ; dev@dpdk.org; > >> >> >akhil.goyal@nxp.com; Trahe, Fiona > >> >> > >> >> >Subject: RE: [dpdk-dev] [PATCH 2/3] app/compress-perf: add > >> >> >performance measurement > >> >> > > >> >> >External Email > >> >> > > >> >> >Hi Shally, Lee, > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Daly, Lee > >> >> >> Sent: Monday, October 15, 2018 8:10 AM > >> >> >> To: Verma, Shally > >> >> >> Cc: Jozwiak, TomaszX ; > dev@dpdk.org; > >> >> >> Trahe, Fiona ; akhil.goyal@nxp.com > >> >> >> Subject: RE: [dpdk-dev] [PATCH 2/3] app/compress-perf: add > >> >> >> performance measurement > >> >> >> > >> >> >> Thanks for your input Shally see comments below. > >> >> >> > >> >> >> > >> >> >> I will be reviewing these changes while Tomasz is out this week. > >> >> >> > >> >> >> > -----Original Message----- > >> >> >> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Verma, > >> >> >> > Shally > >> >> >> > Sent: Friday, October 12, 2018 11:16 AM > >> >> >> > To: Jozwiak, TomaszX ; > >> dev@dpdk.org; > >> >> >> > Trahe, Fiona ; akhil.goyal@nxp.com; De > >> >> >> > Lara Guarch, Pablo > >> >> >> > Cc: De@dpdk.org; Lara@dpdk.org; Guarch@dpdk.org > >> >> >> > Subject: Re: [dpdk-dev] [PATCH 2/3] app/compress-perf: add > >> >> >> > performance measurement > >> >> >> > > >> >> >/// > >> >> > > >> >> >> >Also, why do we need --max-num- sgl-segs as an input option > >> >> >> >from user? Shouldn't input_sz and seg_sz internally decide on > >> >> >> >num-segs? > >> >> >> > Or is it added to serve some other different purpose? > >> >> >> Will have to get back to you on this one, seems illogical to > >> >> >> get this input from user, But I will have to do further > >> >> >> investigation to find if > >> there was a different purpose. > >> >> > > >> >> >[Fiona] Some PMDs have a limit on how many links can be in an sgl > >> >> >chain, e.g. in QAT case the PMD allocates a pool of internal > >> >> >structures of a suitable size during device initialisation, this > >> >> >is not a hard > >> limit but can be configured in .config to give the user control over > >> the memory resources allocated. > >> >> >This perf-tool max-num-sgl-segs is so the user can pick a value > >> >> ><=3D > >> whatever the PMD's max is. > >> >> > >> >> Then also, I believe this could be taken care internally by an app. > >> >> App can choose convenient number of sgl segs as per PMD capability > >> >> and input sz and chunk sz selected by user. > >> >> Just my thoughts. > >> >[Fiona] Then we'd need to add this capability to the API, e.g. add > >> >uint16_t max_nb_segments_per_sgl into the rte_compressdev_info > struct. > >> >Special case 0 means no limit. > >> >We did consider this before, I can't remember why we didn't do it, I > >> >think > >> it's needed. > >> >I'll push an API patch for this in 19.02 and we can remove the > >> >--max-num-sgl-segs param from the performance tool and hardcode it > >> >in > >> the tool in the meantime. > >> >Ok? > >> Yea. Sounds better.