From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0066.outbound.protection.outlook.com [104.47.0.66]) by dpdk.org (Postfix) with ESMTP id 5C0794F9A for ; Sat, 24 Feb 2018 02:17:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w/IuZiwTtVGgIXYaMs1XiECniID3c8jQBpjrppmz6+s=; b=RUPkhmY87oBekvqH9gsiMrONOVq1D1dRXrcJpQ8bioywslLqCA9dZK5+MtkP0ZJl64kwx9+CGV5Fw8qf0EPzbh0ekqDwtP/3lend0ff4CVhXwah1JDHAt8WOEHRNP18D5ZkfUA3FbOzLmdziTS8gsd7XAgYAKKZ3KuwOaVIo2H4= Received: from DB3PR0402MB3852.eurprd04.prod.outlook.com (52.134.71.143) by DB3PR0402MB3836.eurprd04.prod.outlook.com (52.134.71.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Sat, 24 Feb 2018 01:17:24 +0000 Received: from DB3PR0402MB3852.eurprd04.prod.outlook.com ([fe80::8554:d533:15e:1376]) by DB3PR0402MB3852.eurprd04.prod.outlook.com ([fe80::8554:d533:15e:1376%13]) with mapi id 15.20.0506.023; Sat, 24 Feb 2018 01:17:22 +0000 From: Ahmed Mansour To: "Trahe, Fiona" , "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 Thread-Topic: [dpdk-dev] [PATCH] compressdev: implement API Thread-Index: AQHTnFM5yhoAdd9nE0i9ZEIaZBO9+Q== Date: Sat, 24 Feb 2018 01:17:22 +0000 Message-ID: References: <1517595924-25963-1-git-send-email-fiona.trahe@intel.com> <12544144.czVLKRyaz4@xps> <348A99DA5F5B7549AA880327E580B43589325187@IRSMSX101.ger.corp.intel.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ahmed.mansour@nxp.com; x-originating-ip: [192.88.168.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0402MB3836; 7:dtePntu+P2N1deTODsRmb50JI5kk2DmfHHg/imgW1eJVvMESNE+neJeKbqLzuAgtrnOlnVZxTp/6+uXNLWYKNtRr84X7yn/eQtBkhHjBGsmjBwBATBcWI5Nw9M0Smnp821hSHvBG3RyZg3XkEiLAqGvasJw7op8q1hKLjsHU62tJadL+xCOK8dtPWxzwNaLxDFSboNBfaZuhUbpi79a/bnUtsSnNQ9bJpFclQD9l4SVUQ0QYxGN608wcp8jnLW+z x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39380400002)(376002)(346002)(396003)(366004)(39860400002)(199004)(189003)(8936002)(99286004)(7696005)(3660700001)(81166006)(26005)(186003)(53546011)(59450400001)(102836004)(6506007)(97736004)(2201001)(81156014)(33656002)(55016002)(8676002)(478600001)(86362001)(66066001)(14454004)(25786009)(76176011)(3280700002)(9686003)(305945005)(5660300001)(74316002)(3846002)(68736007)(6116002)(7736002)(2900100001)(4326008)(6436002)(54906003)(229853002)(316002)(5890100001)(2906002)(110136005)(105586002)(106356001)(2501003)(6246003)(53936002)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0402MB3836; H:DB3PR0402MB3852.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 3d50d6c7-0790-4920-478f-08d57b245ba7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DB3PR0402MB3836; x-ms-traffictypediagnostic: DB3PR0402MB3836: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(3231205)(944501161)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041288)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:DB3PR0402MB3836; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0402MB3836; x-forefront-prvs: 0593E261C4 received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: grK/2n7UAdTq0qMjwSuQFrPl1SKPL8CSEvUOC0/N6QfSZfcGf8KVye1MgbEw+VyxbzbLcxtqZ/eh37iHfEJ6j9OrP3N/j1TA0db3bjqP7ttpHezVxgppfayjYg/B78LakXqnJvyw2/3X8wv04+Vp+hdzdj3sHGqTTO4wkF+Q5eU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3d50d6c7-0790-4920-478f-08d57b245ba7 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2018 01:17:22.8584 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0402MB3836 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: Sat, 24 Feb 2018 01:17:26 -0000 Hi Fiona,=0A= =0A= Thanks for starting this discussion. In the current API the user must=0A= make 12 API calls just to get information to compress. Maybe there is a=0A= way to simplify. At least for some use cases (stateless). I think a call=0A= sometime next week would be good to help clarify coalesce some of the=0A= complexity.=0A= =0A= I added specific comments inline.=0A= =0A= Thanks,=0A= =0A= Ahmed=0A= =0A= On 2/21/2018 2:12 PM, Trahe, Fiona wrote:=0A= > We've been struggling with the idea of session in compressdev.=0A= >=0A= > Is it really a session? =0A= > - It's not in the same sense as cryptodev where it's used to hold a key,= and maps to a Security Association.=0A= > - It's a set of immutable data that is needed with the op and stream to = perform the operation.=0A= > - It inherited from cryptodev the ability to be set up for multiple driv= er types and used across any =0A= > devices of those types. For stateful ops this facility can't be used.= =0A= > For stateless we don't think it's important, and think it's unlikely = to be used.=0A= > - Drivers use it to prepare private data, set up resources, do pre-work,= so there's=0A= > less work to be done on the data path. Initially we didn't have a str= eam, we do now,=0A= > this may be a better alternative place for that work.=0A= > So we've been toying with the idea of getting rid of the session. =0A= [Ahmed] In our proprietary API the stream and session are one. A session=0A= holds many properties like the op-type, instead of having this=0A= information in the op itself. This way we lower the per op setup cost.=0A= This also allows rapid reuse of stateful infrastructure, once a stream=0A= is closed on a stateful session, the next op (stream) on this session=0A= reuses the stateful storage. Obviously if a stream is in "pause mode" on=0A= a session, all following ops that may be unrelated to this=0A= stream/session must also wait until this current stream is closed or=0A= aborted before the infrastructure can be reused.=0A= >=0A= > We also struggle with the idea of setting up a stream for stateless ops.= =0A= > - Well, really I just think the name is misleading, i.e. there's no pro= blem with setting =0A= > up some private PMD data to use with stateless operations, just calli= ng it a=0A= > stream doesn't seem right.=0A= [Ahmed] I agree. The op has all the necessary information to process it=0A= in the current API? Both the stream and the op are one time use. We=0A= can't attach multiple similar ops to a single stream/session and rely on=0A= their properties to simplify op setup, so why the hassle.=0A= >=0A= > So putting above thoughts together I want to propose:=0A= > - Removal of the session and all associated APIs.=0A= > - Passing in one of three data types in the rte_comp_op=0A= > =0A= > union {=0A= > struct rte_comp_xform *xform;=0A= > /**< Immutable compress/decompress params */=0A= > void *pmd_stateless_data;=0A= > /**< Stateless private PMD data derived from an rte_comp_xform=0A= > * rte_comp_stateless_data_init() must be called on a device =0A= > * before sending any STATELESS operations. If the PMD returns a = non-NULL=0A= > * value the handle must be attached to subsequent STATELESS oper= ations.=0A= > * If a PMD returns NULL, then the xform should be passed directl= y to each op =0A= > */=0A= > void *stream;=0A= > /* Private PMD data derived initially from an rte_comp_xform, whi= ch holds state=0A= > * and history data and evolves as operations are processed.=0A= > * rte_comp_stream_create() must be called on a device for all ST= ATEFUL =0A= > * data streams and the resulting stream attached=0A= > * to the one or more operations associated with the data stream.= =0A= > * All operations in a stream must be sent to the same device.=0A= > */=0A= > }=0A= [Ahmed] I like this setup, but I am not sure in what cases the xform=0A= immutable would be used. I understand the other two.=0A= > Notes: =0A= > 1. Internally if a PMD wants to use the exact same data structure for bot= h it can do, =0A= > just on the API I think it's better if they're named differently wit= h =0A= > different comments.=0A= > 2. I'm not clear of the constraints if any, which attach to the pmd_state= less_data=0A= > For our PMD it would only hold immutable data as the session did, an= d so=0A= > could be attached to many ops in parallel.=0A= > Is this true for all PMDs or are there constraints which should be c= alled out?=0A= > Is it limited to a specific device, qp, or to be used on one op at a= time?=0A= > 3. Am open to other naming suggestions, just trying to capture the essenc= e=0A= > of these data structs better than our current API does.=0A= >=0A= > We would put some more helper fns and structure around the above code if = people=0A= > are in agreement, just want to see if the concept flies before going furt= her?=0A= >=0A= > Fiona=0A= > =0A= >=0A= >=0A= =0A=