> -----Original Message-----
> From: Verma, Shally [mailto:shally.ve...@cavium.com]
> Sent: Wednesday, October 17, 2018 8:43 AM
> To: Trahe, Fiona <fiona.tr...@intel.com>; Daly, Lee <lee.d...@intel.com>
> Cc: Jozwiak, TomaszX <tomaszx.jozw...@intel.com>; dev@dpdk.org;
> akhil.go...@nxp.com
> Subject: RE: [dpdk-dev] [PATCH 2/3] app/compress-perf: add performance
> measurement
>
>
>
> >-----Original Message-----
> >From: Trahe, Fiona <fiona.tr...@intel.com>
> >Sent: 17 October 2018 20:04
> >To: Daly, Lee <lee.d...@intel.com>; Verma, Shally <shally.ve...@cavium.com>
> >Cc: Jozwiak, TomaszX <tomaszx.jozw...@intel.com>; dev@dpdk.org;
> >akhil.go...@nxp.com; Trahe, Fiona
> <fiona.tr...@intel.com>
> >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 <shally.ve...@cavium.com>
> >> Cc: Jozwiak, TomaszX <tomaszx.jozw...@intel.com>; dev@dpdk.org; Trahe,
> >> Fiona
> >> <fiona.tr...@intel.com>; akhil.go...@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-boun...@dpdk.org] On Behalf Of Verma, Shally
> >> > Sent: Friday, October 12, 2018 11:16 AM
> >> > To: Jozwiak, TomaszX <tomaszx.jozw...@intel.com>; dev@dpdk.org; Trahe,
> >> > Fiona <fiona.tr...@intel.com>; akhil.go...@nxp.com; De Lara Guarch, Pablo
> >> > <pablo.de.lara.gua...@intel.com>
> >> > Cc: d...@dpdk.org; l...@dpdk.org; gua...@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 <= 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?
