From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 4805849E0 for ; Mon, 26 Feb 2018 12:25:00 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 03:24:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,396,1515484800"; d="scan'208";a="20264285" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by fmsmga007.fm.intel.com with ESMTP; 26 Feb 2018 03:24:57 -0800 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.188]) by irsmsx105.ger.corp.intel.com ([169.254.7.221]) with mapi id 14.03.0319.002; Mon, 26 Feb 2018 11:24:56 +0000 From: "Trahe, Fiona" To: Ahmed Mansour , "dev@dpdk.org" , "Shally.Verma@cavium.com" CC: "De Lara Guarch, Pablo" , "Athreya, Narayana Prasad" , "Gupta, Ashish" , "Sahu, Sunila" , "Challa, Mahipal" , "Jain, Deepak K" , Hemant Agrawal , "Roy Pledge" , Youri Querry , "Trahe, Fiona" Thread-Topic: [dpdk-dev] [PATCH] compressdev: implement API Thread-Index: AQHTnFNA34V0d0oQkkqZkaaruzarZKO2qxcw Date: Mon, 26 Feb 2018 11:24:55 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B435893279DB@IRSMSX101.ger.corp.intel.com> References: <1517595924-25963-1-git-send-email-fiona.trahe@intel.com> <12544144.czVLKRyaz4@xps> <348A99DA5F5B7549AA880327E580B43589325187@IRSMSX101.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWVhY2YyY2YtYTZjZS00OGJlLWFkNTEtNmZiYzZlMDg0ZDBmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjdFM2ViN3BHM3RrTmhkZU5oOVJZNHd5dGJxK2pIcUgzelROVmM2eXowU3c9In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] compressdev: implement API 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: Mon, 26 Feb 2018 11:25:00 -0000 > -----Original Message----- > From: Ahmed Mansour [mailto:ahmed.mansour@nxp.com] > Sent: Saturday, February 24, 2018 1:17 AM > To: Trahe, Fiona ; dev@dpdk.org; Shally.Verma@cavi= um.com > Cc: De Lara Guarch, Pablo ; Athreya, Nara= yana Prasad > ; Gupta, Ashish ; Sahu, Sunila > ; Challa, Mahipal ; Ja= in, Deepak K > ; Hemant Agrawal ; Roy P= ledge > ; Youri Querry > Subject: Re: [dpdk-dev] [PATCH] compressdev: implement API >=20 > Hi Fiona, >=20 > Thanks for starting this discussion. In the current API the user must > make 12 API calls just to get information to compress. Maybe there is a > way to simplify. At least for some use cases (stateless). I think a call > sometime next week would be good to help clarify coalesce some of the > complexity. [Fiona] Would 10:30 GMT on Wednesday 28th Feb suit? >=20 > I added specific comments inline. >=20 > Thanks, >=20 > Ahmed >=20 > On 2/21/2018 2:12 PM, Trahe, Fiona wrote: > > We've been struggling with the idea of session in compressdev. > > > > Is it really a session? > > - It's not in the same sense as cryptodev where it's used to hold a ke= y, and maps to a Security > Association. > > - It's a set of immutable data that is needed with the op and stream t= o perform the operation. > > - It inherited from cryptodev the ability to be set up for multiple dr= iver types and used across any > > devices of those types. For stateful ops this facility can't be use= d. > > For stateless we don't think it's important, and think it's unlikel= y to be used. > > - Drivers use it to prepare private data, set up resources, do pre-wor= k, so there's > > less work to be done on the data path. Initially we didn't have a s= tream, we do now, > > this may be a better alternative place for that work. > > So we've been toying with the idea of getting rid of the session. > [Ahmed] In our proprietary API the stream and session are one. A session > holds many properties like the op-type, instead of having this > information in the op itself. This way we lower the per op setup cost. > This also allows rapid reuse of stateful infrastructure, once a stream > is closed on a stateful session, the next op (stream) on this session > reuses the stateful storage. Obviously if a stream is in "pause mode" on > a session, all following ops that may be unrelated to this > stream/session must also wait until this current stream is closed or > aborted before the infrastructure can be reused. > > > > We also struggle with the idea of setting up a stream for stateless ops= . > > - Well, really I just think the name is misleading, i.e. there's no p= roblem with setting > > up some private PMD data to use with stateless operations, just cal= ling it a > > stream doesn't seem right. > [Ahmed] I agree. The op has all the necessary information to process it > in the current API? Both the stream and the op are one time use. We > can't attach multiple similar ops to a single stream/session and rely on > their properties to simplify op setup, so why the hassle. > > > > So putting above thoughts together I want to propose: > > - Removal of the session and all associated APIs. > > - Passing in one of three data types in the rte_comp_op > > > > union { > > struct rte_comp_xform *xform; > > /**< Immutable compress/decompress params */ > > void *pmd_stateless_data; > > /**< Stateless private PMD data derived from an rte_comp_xform > > * rte_comp_stateless_data_init() must be called on a device > > * before sending any STATELESS operations. If the PMD returns = a non-NULL > > * value the handle must be attached to subsequent STATELESS op= erations. > > * If a PMD returns NULL, then the xform should be passed direc= tly to each op > > */ > > void *stream; > > /* Private PMD data derived initially from an rte_comp_xform, w= hich holds state > > * and history data and evolves as operations are processed. > > * rte_comp_stream_create() must be called on a device for all = STATEFUL > > * data streams and the resulting stream attached > > * to the one or more operations associated with the data strea= m. > > * All operations in a stream must be sent to the same device. > > */ > > } > [Ahmed] I like this setup, but I am not sure in what cases the xform > immutable would be used. I understand the other two. [Fiona] The xform is there because I don't know yet what limitations may ap= ply to the pmd_stateless_data. If it has no limitation and once set up once on a devic= e=20 can be attached simultaneously to any op sent to any qp on that device then we don't need the xform. But I understood from Shally's earlier reques= t for setting up a stream on a stateless request that some resources are allocated, so we may need to document some limitations. In this case the xform may be a better path for PMDs which don't have the s= ame limitations. =20 > > Notes: > > 1. Internally if a PMD wants to use the exact same data structure for b= oth it can do, > > just on the API I think it's better if they're named differently w= ith > > different comments. > > 2. I'm not clear of the constraints if any, which attach to the pmd_sta= teless_data > > For our PMD it would only hold immutable data as the session did, = and so > > could be attached to many ops in parallel. > > Is this true for all PMDs or are there constraints which should be= called out? > > Is it limited to a specific device, qp, or to be used on one op at= a time? > > 3. Am open to other naming suggestions, just trying to capture the esse= nce > > of these data structs better than our current API does. > > > > We would put some more helper fns and structure around the above code i= f people > > are in agreement, just want to see if the concept flies before going fu= rther? > > > > Fiona > > > > > >