From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0062.outbound.protection.outlook.com [104.47.40.62]) by dpdk.org (Postfix) with ESMTP id 17FC82BDF for ; Tue, 27 Feb 2018 06:53:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dy2z50TQyR4ThjIvRQcpFXz23HCRi/0zlxbpx8sO4iE=; b=R5tTps1ClDZfonfMZzacIRyZACVh/dS5Ca/NHPq5saJzuU3BSRo3L420MorKBSjGU4MZgEf/7E0Eix1HG+j4iTW+C9d+L+YSIXCr+3ykAE0twxU/ZK9dH2TSQZYDAIf5DCJBEzoMU3iyZMDFoNHi66lAr69aFHTMgjFKjurUvnw= Received: from MWHPR0701MB3641.namprd07.prod.outlook.com (10.167.236.162) by MWHPR0701MB3788.namprd07.prod.outlook.com (10.167.237.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Tue, 27 Feb 2018 05:53:38 +0000 Received: from MWHPR0701MB3641.namprd07.prod.outlook.com ([fe80::3992:467f:ba7c:dc07]) by MWHPR0701MB3641.namprd07.prod.outlook.com ([fe80::3992:467f:ba7c:dc07%13]) with mapi id 15.20.0527.021; Tue, 27 Feb 2018 05:53:37 +0000 From: "Verma, Shally" To: Ahmed Mansour , "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: AQHTnFM4Vpm7OG1Ltk6wDJVFHhqAyaO32QHQ Date: Tue, 27 Feb 2018 05:53:37 +0000 Message-ID: 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-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shally.Verma@cavium.com; x-originating-ip: [115.113.156.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR0701MB3788; 7:xFp4YL+iLTAJDK6dKhmF1TRs8uL37J9iJ8smd+FwUEQlKK+8OIM42ceDWOsgPrhCG/aeu+dtbztmnRF83CvkTmIC/y95H96cReWbAPSJcv9VbSPiZu9wUI+DYcF/xZ8DcHhfKslG+K3SnXb9deINYWnc93K8WChorY5IXENma1uaxtt7wVYq2JTp/06QsrkRHOhzgKjyuFcbePrnaPEDtddYFOwk++jNit5+GU+5MGkAH2ZkFy1vjngI1gcDAL3H x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(366004)(39380400002)(396003)(346002)(39860400002)(376002)(199004)(189003)(13464003)(305945005)(5660300001)(7736002)(106356001)(66066001)(74316002)(72206003)(966005)(59450400001)(6506007)(186003)(55236004)(26005)(229853002)(53546011)(102836004)(5890100001)(25786009)(5250100002)(561944003)(6436002)(8936002)(2950100002)(81166006)(81156014)(8676002)(86362001)(4326008)(2501003)(93886005)(2906002)(3660700001)(105586002)(97736004)(33656002)(2900100001)(7696005)(3846002)(6116002)(8656006)(99286004)(68736007)(478600001)(76176011)(55016002)(54906003)(316002)(3280700002)(14454004)(6306002)(9686003)(53936002)(6246003)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR0701MB3788; H:MWHPR0701MB3641.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 6f49ee88-2314-4b25-e448-08d57da671f3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR0701MB3788; x-ms-traffictypediagnostic: MWHPR0701MB3788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(131327999870524)(185117386973197)(21532816269658)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231220)(944501161)(52105095)(93006095)(93001095)(6041288)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR0701MB3788; BCL:0; PCL:0; RULEID:; SRVR:MWHPR0701MB3788; x-forefront-prvs: 05961EBAFC received-spf: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: TQHWgk/Ztz/uH3VtPh8U1pxtyxeVp/WJ6GVQ3QP7hOD7/NvdTskOxUgAfqsQa86gz9ohEK98lyBtVv0rN8ZKtyP2TnRbnCOrSAn8+uzW+9sfHTa+afTEcCnj+JblWBIlwes2BbeFQK29/E269vl3XdkcZmjPJfaFyGi8gsCGdeg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6f49ee88-2314-4b25-e448-08d57da671f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2018 05:53:37.0924 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0701MB3788 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: Tue, 27 Feb 2018 05:53:41 -0000 >-----Original Message----- >From: Ahmed Mansour [mailto:ahmed.mansour@nxp.com] >Sent: 27 February 2018 03:05 >To: Verma, Shally ; Trahe, Fiona ; 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 > >> Hi Fiona, Ahmed >>> Hi Fiona, >>> >>> 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 cal= l >>> sometime next week would be good to help clarify coalesce some of the >>> complexity. >>> >>> I added specific comments inline. >>> >>> Thanks, >>> >>> Ahmed >>> >>> 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 k= ey, and maps to a Security Association. >>>> - It's a set of immutable data that is needed with the op and stream = to perform the operation. >>>> - It inherited from cryptodev the ability to be set up for multiple d= river types and used across any >>>> devices of those types. For stateful ops this facility can't be us= ed. >>>> For stateless we don't think it's important, and think it's unlike= ly to be used. >>>> - Drivers use it to prepare private data, set up resources, do pre-wo= rk, so there's >>>> less work to be done on the data path. Initially we didn't have a = stream, 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 sessio= n >>> 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" o= n >>> 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 op= s. >>>> - Well, really I just think the name is misleading, i.e. there's no = problem with setting >>>> up some private PMD data to use with stateless operations, just ca= lling 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 o= n >>> their properties to simplify op setup, so why the hassle. >> [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 i= s not possible for stateful 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. >[Ahmed] Is there an advantage to exposing load balancing to the user? I >do not see load balancing as a feature within itself. Can the PMD take >care of this? I guess a system that has [Shally] I assume idea was to leverage multiple PMDs that are available in = system (say QAT+SW ZLIB) and I believe matter of load-balancing came out of= one of the earlier discussion with Fiona on RFC v1. http://dev.dpdk.narkiv= e.com/CHS5l01B/dpdk-dev-rfc-v1-doc-compression-api-for-dpdk#post3 So, I wait for her comments on this. But in any case, with changed notion t= oo it looks achievable to me, if so is desired. >> In current proposal, stream logically represent data and hold its specif= ic information and session is generic information that can be >applied on multiple data. If we want to combine stream and session. Then o= ne way to look at this is: >> >> "let application only allocate and initialize session with rte_comp_xfor= m (and possibly op type) information so that PMD can do one- >time setup and allocate enough resources. Once attached to op, cannot be r= eused until that op is fully processed. So, if app has 16 >data elements to process in a burst, it will setup 16 sessions." >[Ahmed] Why not allow multiple inflight stateless ops with the same >session? Stateless by definition guarantees that the resources used to >work on one up will be free after the op is processed. That means that >even if an op fails to process correctly on a session, it will have no >effect on the next op since there is not interdependence. This assumes >that the resources are shareable between hardware instances for >stateless. That is not a bad assumption since hardware should not need >more than the data of the op itself to work on a statelss op. [Shally] multiple ops in-flight can connect to same session but I assume y= ou agree then they cannot execute in parallel i.e. only one op at-a-time ca= n use session here? And as far as I understand your PMD works this way. You= r HW execute one op at-a-time from queue?! >> This is same as what Ahmed suggested. For a particular load-balancing ca= se suggested above, If application want, can initialize >different sessions on multiple devices with same xform so that each is pre= pared to process ops. Application can then fanout stateless >ops to multiple devices for load-balancing but then it would need to keep = map of device & a session map. >> >> If this sound feasible, then I too believe we can rather get rid of eith= er and keep one (possibly session but am open with stream as >well). >> 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. >> So, then I see it as: >> >> - A stream(or session whichever name is chosen) can be used with only on= e-op at-a-time >> - It can be re-used when previously attached op is processed >> - if it is stream then currently it is allocated from PMD managed pool = whereas Sessions are allocated from application created >mempool. >> In either of case, I would expect to review pool management API >> >> With this in mind, below are few of my comments >> >>>> 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 o= perations. >>>> * If a PMD returns NULL, then the xform should be passed dire= ctly to each op >>>> */ >> [Shally] It sounds like stateless_data_init() nothing more than a replac= ement of session_init(). >> So, this is needed neither if we retain session concept nor if we retai= n stream concept ( rte_comp_stream_create() with >op_type: stateless can serve same purpose). >> It should be sufficient to provide either stream (or session) pointer. >> >>>> void *stream; >>>> /* Private PMD data derived initially from an rte_comp_xform, = which 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 stre= am. >>>> * 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. >> [Shally] my understanding is xform will be mapped by PMD to its internal= ly managed stream(or session data structure). And then we >can remove STATEFUL reference here and just say stream(or session) it belo= ngs to. However, This condition still apply: >> *All operations that belong to same stream must be sent to the sa= me device.* >> >>>> Notes: >>>> 1. Internally if a PMD wants to use the exact same data structure for = both it can do, >>>> just on the API I think it's better if they're named differently = with >>>> different comments. >>>> 2. I'm not clear of the constraints if any, which attach to the pmd_st= ateless_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 b= e called out? >>>> Is it limited to a specific device, qp, or to be used on one op a= t a time? >>>> 3. Am open to other naming suggestions, just trying to capture the ess= ence >>>> of these data structs better than our current API does. >>>> >>>> We would put some more helper fns and structure around the above code = if people >>>> are in agreement, just want to see if the concept flies before going f= urther? >>>> >>>> Fiona >>>> >>>> >>>> >>