From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Verma, Shally" Subject: Re: [PATCH] compressdev: implement API Date: Mon, 5 Mar 2018 14:32:38 +0000 Message-ID: References: <1517595924-25963-1-git-send-email-fiona.trahe@intel.com> <12544144.czVLKRyaz4@xps> <348A99DA5F5B7549AA880327E580B43589325187@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B4358932983C@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B43589329F78@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B4358932A333@IRSMSX101.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "De Lara Guarch, Pablo" , "Athreya, Narayana Prasad" , "Gupta, Ashish" , "Sahu, Sunila" , "Challa, Mahipal" , "Jain, Deepak K" , Hemant Agrawal , Roy Pledge , Youri Querry To: Ahmed Mansour , "Trahe, Fiona" , "dev@dpdk.org" Return-path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0088.outbound.protection.outlook.com [104.47.40.88]) by dpdk.org (Postfix) with ESMTP id ACC4A374 for ; Mon, 5 Mar 2018 15:32:42 +0100 (CET) In-Reply-To: Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" >-----Original Message----- >From: Ahmed Mansour [mailto:ahmed.mansour@nxp.com] >Sent: 03 March 2018 01:19 >To: Trahe, Fiona ; Verma, Shally ; dev@dpdk.org >Cc: De Lara Guarch, Pablo ; Athreya, Naray= ana Prasad ; >Gupta, Ashish ; Sahu, Sunila ; Challa, Mahipal >; Jain, Deepak K ; Hem= ant Agrawal ; Roy >Pledge ; Youri Querry >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 xf= orm_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 t= o send stateless ops. >> If PMD returns shareable, then it doesn't need to call again and can att= ach this to every stateless op going to that device. >> If PMD returns SINGLE_OP then it must call xform_init() before every oth= er >> stateless op it wants to have inflight simultaneously. This does not mea= n it must be called before every op, >> but probably will set up a batch of priv_xforms - it can reuse each pri= v_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 evalu= ate effectiveness. So far, we have never exercised this way and left it to = application to attach different session (or stream) to op for maximum perfo= rmance gain. So, I would say, may it be ok to have flag feature in first pl= ace 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/NO= N-SHAREABLE xform_priv handle?!