From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0051.outbound.protection.outlook.com [104.47.1.51]) by dpdk.org (Postfix) with ESMTP id 23D3628F3 for ; Mon, 26 Feb 2018 22:35: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=ieIfPbHCdRdRXcaCGnBKyg70u5dybswYnbIwdX8YV2k=; b=LGsis4WKtoAKzNWKA5p+haLxUC5TXOMP7II4A+Q8jgV9giGbMqDRLJzjNQc/tMyxFRHGt45LBXsZCzbCseEjgbMOmrAPSTDpWEYeQmPiWrnG+g785hIDzODkiTxIi4KDc9sBlkxgVvK2Y8EhcDIwHm11cEWl9UaRjVYakCRm7Vk= Received: from DB3PR0402MB3852.eurprd04.prod.outlook.com (52.134.71.143) by DB3PR0402MB3785.eurprd04.prod.outlook.com (52.134.71.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Mon, 26 Feb 2018 21:35:25 +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.0527.021; Mon, 26 Feb 2018 21:35:23 +0000 From: Ahmed Mansour To: "Verma, Shally" , "Trahe, Fiona" , "dev@dpdk.org" 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: Mon, 26 Feb 2018 21:35:23 +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; DB3PR0402MB3785; 7:bd6CAxwVvH+onRW9Xm1cfG1fDsKvfwvHW/BmcR9RFbOMO16/+hs1I6aiP+2Y8mnch5ulX1i+D3fQnXztrxpNfieTN1wUYMQduaJ32HPWkHtE2IDqZApgE4a1XJfhu3B0nNTab62gnfMfWuJPtyFSvj010moFLa19aku6tMglJj/FyQfA50cnBq7yaB9DsatYMqFul2NFDdEfhFGUiUW9SkiRrlSl8AEVWdByms70SAJ8xVURs8xI7Cq1vxqFHBgj x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(396003)(39380400002)(346002)(189003)(199004)(43544003)(4326008)(106356001)(93886005)(53936002)(229853002)(25786009)(6246003)(5660300001)(26005)(478600001)(55016002)(2900100001)(186003)(3846002)(68736007)(2906002)(59450400001)(99286004)(6116002)(54906003)(53546011)(110136005)(102836004)(3280700002)(14454004)(316002)(9686003)(6436002)(6506007)(3660700001)(97736004)(561944003)(81166006)(8676002)(76176011)(86362001)(33656002)(81156014)(8936002)(105586002)(74316002)(7736002)(2501003)(5890100001)(5250100002)(305945005)(66066001)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0402MB3785; H:DB3PR0402MB3852.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 89b4e14e-36db-4c47-adc6-08d57d60d7e7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DB3PR0402MB3785; x-ms-traffictypediagnostic: DB3PR0402MB3785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231220)(944501161)(52105095)(93006095)(93001095)(3002001)(6055026)(6041288)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB3PR0402MB3785; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0402MB3785; x-forefront-prvs: 05954A7C45 received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: WgLWuIVVc+dcShL1zFXnoCboI+WKBNBKdSkkOKEXYHj3iSC6W7m4xMTRvVOws4V+xbf3bX7DqzfTKcLRUMlULLA00+t5Ou59Y3swTOSDEluReMrrGXM9TSm0CGV6bt1LGoPO5xETSrgNxOYn/5MQRYv5AZtGSMVkzmNmF3OY/qg= 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: 89b4e14e-36db-4c47-adc6-08d57d60d7e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2018 21:35:23.4629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0402MB3785 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 21:35:27 -0000 > Hi Fiona, Ahmed=0A= >> 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 ke= y, and maps to a Security Association.=0A= >>> - It's a set of immutable data that is needed with the op and stream t= o perform the operation.=0A= >>> - It inherited from cryptodev the ability to be set up for multiple dr= iver types and used across any=0A= >>> devices of those types. For stateful ops this facility can't be use= d.=0A= >>> For stateless we don't think it's important, and think it's unlikel= y to be used.=0A= >>> - Drivers use it to prepare private data, set up resources, do pre-wor= k, so there's=0A= >>> less work to be done on the data path. Initially we didn't have a s= tream, 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= >>> 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 p= roblem with setting=0A= >>> up some private PMD data to use with stateless operations, just cal= ling 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= > [Shally] As per my knowledge, session came with idea in DPDK, if system = has multiple devices setup to do similar jobs then application can fan out = ops to any of them for load-balancing. Though it is not possible for statef= ul ops but it still can work for stateless. If there's an application which= only have stateless ops to process then I see this is still useful feature= to support.=0A= [Ahmed] Is there an advantage to exposing load balancing to the user? I=0A= do not see load balancing as a feature within itself. Can the PMD take=0A= care of this? I guess a system that has=0A= > In current proposal, stream logically represent data and hold its specifi= c information and session is generic information that can be applied on mul= tiple data. If we want to combine stream and session. Then one way to look = at this is:=0A= >=0A= > "let application only allocate and initialize session with rte_comp_xform= (and possibly op type) information so that PMD can do one-time setup and a= llocate enough resources. Once attached to op, cannot be reused until that = op is fully processed. So, if app has 16 data elements to process in a burs= t, it will setup 16 sessions."=0A= [Ahmed] Why not allow multiple inflight stateless ops with the same=0A= session? Stateless by definition guarantees that the resources used to=0A= work on one up will be free after the op is processed. That means that=0A= even if an op fails to process correctly on a session, it will have no=0A= effect on the next op since there is not interdependence. This assumes=0A= that the resources are shareable between hardware instances for=0A= stateless. That is not a bad assumption since hardware should not need=0A= more than the data of the op itself to work on a statelss op.=0A= > This is same as what Ahmed suggested. For a particular load-balancing cas= e suggested above, If application want, can initialize different sessions o= n multiple devices with same xform so that each is prepared to process ops.= Application can then fanout stateless ops to multiple devices for load-ba= lancing but then it would need to keep map of device & a session map.=0A= >=0A= > If this sound feasible, then I too believe we can rather get rid of eithe= r and keep one (possibly session but am open with stream as well). =0A= > However, regardless of case whether we live with name stream or session, = I don't see much deviation from current API spec except description and few= modifications/additions as identified.=0A= > So, then I see it as:=0A= >=0A= > - A stream(or session whichever name is chosen) can be used with only one= -op at-a-time=0A= > - It can be re-used when previously attached op is processed=0A= > - if it is stream then currently it is allocated from PMD managed pool w= hereas Sessions are allocated from application created mempool.=0A= > In either of case, I would expect to review pool management API=0A= >=0A= > With this in mind, below are few of my comments=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 op= erations.=0A= >>> * If a PMD returns NULL, then the xform should be passed direc= tly to each op=0A= >>> */=0A= > [Shally] It sounds like stateless_data_init() nothing more than a replace= ment of session_init(). =0A= > So, this is needed neither if we retain session concept nor if we retain= stream concept ( rte_comp_stream_create() with op_type: stateless can serv= e same purpose). =0A= > It should be sufficient to provide either stream (or session) pointer.= =0A= >=0A= >>> void *stream;=0A= >>> /* Private PMD data derived initially from an rte_comp_xform, w= hich 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 = STATEFUL=0A= >>> * data streams and the resulting stream attached=0A= >>> * to the one or more operations associated with the data strea= m.=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= > [Shally] my understanding is xform will be mapped by PMD to its internall= y managed stream(or session data structure). And then we can remove STATEF= UL reference here and just say stream(or session) it belongs to. However, T= his condition still apply:=0A= > *All operations that belong to same stream must be sent to the sam= e device.*=0A= >=0A= >>> Notes:=0A= >>> 1. Internally if a PMD wants to use the exact same data structure for b= oth it can do,=0A= >>> just on the API I think it's better if they're named differently w= ith=0A= >>> different comments.=0A= >>> 2. I'm not clear of the constraints if any, which attach to the pmd_sta= teless_data=0A= >>> For our PMD it would only hold immutable data as the session did, = and so=0A= >>> could be attached to many ops in parallel.=0A= >>> Is this true for all PMDs or are there constraints which should be= called 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 esse= nce=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 i= f people=0A= >>> are in agreement, just want to see if the concept flies before going fu= rther?=0A= >>>=0A= >>> Fiona=0A= >>>=0A= >>>=0A= >>>=0A= >=0A= =0A=