On 3/5/2018 9:32 AM, Verma, Shally wrote:
>
>> -----Original Message-----
>> From: Ahmed Mansour [mailto:ahmed.mans...@nxp.com]
>> Sent: 03 March 2018 01:19
>> To: Trahe, Fiona <fiona.tr...@intel.com>; Verma, Shally
>> <shally.ve...@cavium.com>; dev@dpdk.org
>> Cc: De Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com>; Athreya,
>> Narayana Prasad <narayanaprasad.athr...@cavium.com>;
>> Gupta, Ashish <ashish.gu...@cavium.com>; Sahu, Sunila
>> <sunila.s...@cavium.com>; Challa, Mahipal
>> <mahipal.cha...@cavium.com>; Jain, Deepak K <deepak.k.j...@intel.com>;
>> Hemant Agrawal <hemant.agra...@nxp.com>; Roy
>> Pledge <roy.ple...@nxp.com>; Youri Querry <youri.querr...@nxp.com>
>> Subject: Re: [dpdk-dev] [PATCH] compressdev: implement API
>>
>> On 3/2/2018 4:53 AM, Trahe, Fiona wrote:
>>>> On 3/1/2018 9:41 AM, Trahe, Fiona wrote:
>>>>> Hi Shally
>>>>>
>>>>> //snip//
>>>>>> [Shally] This looks better to me. So it mean app would always call
>>>>>> xform_init() for stateless and attach
>>>> an
>>>>>> updated priv_xform to ops (depending upon if there's shareable or not).
>>>>>> So it does not need to have
>>>>>> NULL pointer on priv_xform. right?
>>>>>>
>>>>> [Fiona] yes. The PMD must return a valid priv_xform pointer.
>>>> [Ahmed] What I understood is that the xform_init will be called once
>>>> initially. if the @flag returned is NONE_SHAREABLE then the application
>>>> must not attach two inflight ops to the same @priv_xform? Otherwise the
>>>> application can attach many ops in flight to the @priv_xform?
>>> [Fiona Yes. App calls the xform_init() once on a device where it plans to
>>> send stateless ops.
>>> If PMD returns shareable, then it doesn't need to call again and can attach
>>> this to every stateless op going to that device.
>>> If PMD returns SINGLE_OP then it must call xform_init() before every other
>>> stateless op it wants to have inflight simultaneously. This does not mean
>>> it must be called before every op,
>>> but probably will set up a batch of priv_xforms - it can reuse each
>>> priv_xform once the op finishes with it.
>> [Ahmed] @Shally Can this complexity of managing the NONE_SHAREABLE mode
>> be pushed into the PMD? A flexible stockpile can be kept and maintained
>> by the PMD and it can be increased or decreased based on
>> low-water/high-water thresholds
> [Shally] It is doable to manage within PMD but need to do hands on to
> evaluate effectiveness. So far, we have never exercised this way and left it
> to application to attach different session (or stream) to op for maximum
> performance gain. So, I would say, may it be ok to have flag feature in first
> place and deprecate later, if it not required?! Or just have API without any
> flag option and add a feature flag to indicate PMD support for
> SHAREABLE/NON-SHAREABLE xform_priv handle?!
[Ahmed] Either way looks ok to me. I see your point about performance.
If this is in the PMD it will have to constantly guess how much memory
the user needs and accommodate dynamically. The user can implement a
similar scheme or if the application is simple they can pre-allocate and
reduce CPU allocation de-allocation overhead.
