From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0048.outbound.protection.outlook.com [104.47.1.48]) by dpdk.org (Postfix) with ESMTP id D83081B3FC for ; Mon, 29 Jan 2018 18:16:08 +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=f9/CIYr9kJApL2o5sYi8iyHHVUZXGrU+XU90SFavpQ4=; b=qiIRK7zSXWT/t0s7gG6G34yApuNiwUjuE/jT5zfysr+IzXR0KZRCsSsv4+UosGt9AVDucAjkYes7Hh+kpz/jeNLoy5SzHMhpDJmjC/JZrl8YDzcjdwe2CV13Ku/yCwsR3OuR1gTDN12EU5ATD0lon0dRBgYt+4vM2c/TptTwG+g= Received: from AM0PR0402MB3842.eurprd04.prod.outlook.com (52.133.39.138) by AM0PR0402MB3330.eurprd04.prod.outlook.com (52.133.44.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Mon, 29 Jan 2018 17:16:05 +0000 Received: from AM0PR0402MB3842.eurprd04.prod.outlook.com ([fe80::c5aa:5e21:5101:240c]) by AM0PR0402MB3842.eurprd04.prod.outlook.com ([fe80::c5aa:5e21:5101:240c%13]) with mapi id 15.20.0444.016; Mon, 29 Jan 2018 17:16:05 +0000 From: Ahmed Mansour To: "Verma, Shally" , "Trahe, Fiona" , "dev@dpdk.org" , Akhil Goyal CC: "Challa, Mahipal" , "Athreya, Narayana Prasad" , "De Lara Guarch, Pablo" , "Gupta, Ashish" , "Sahu, Sunila" , "Jain, Deepak K" , Hemant Agrawal , "Roy Pledge" , Youri Querry Thread-Topic: [RFC v3 1/1] lib: add compressdev API Thread-Index: AQHTdc0OzPqMCHpj+U2ot72hAgksuw== Date: Mon, 29 Jan 2018 17:16:05 +0000 Message-ID: References: <1511542566-10455-1-git-send-email-fiona.trahe@intel.com> <1513360153-15036-1-git-send-email-fiona.trahe@intel.com> <348A99DA5F5B7549AA880327E580B435892FCF50@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B435893011B0@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; AM0PR0402MB3330; 7:cQAXn/WCBUp30M0EBxWw3VcZOd3pH+DxLjEvBs+ympLdFCfvllMWLqOef0KQvwZr6UkaASRfe2bRQDbQOJr9Ez1CxFBbEtnWWSCQgqjzllOdNwLWVvnF9mLkdIl8CEZ8kadQmyXZFutTgaqTZ1lTn7jYG3Tb0HjBOoOE3wdQ+HWPUcG6iopobSoACgsa5DrWra96p5hp9EdB7og+NSRudVgaA3corOPd7oJTUTGv45nUL1OHrMKvvf0PlHlpktOl x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(346002)(366004)(396003)(376002)(13464003)(51444003)(53754006)(199004)(189003)(25786009)(74316002)(575784001)(53936002)(6506007)(7736002)(81166006)(6306002)(86362001)(8676002)(9686003)(3660700001)(102836004)(3280700002)(81156014)(6436002)(76176011)(2906002)(8936002)(26005)(54906003)(316002)(99286004)(59450400001)(97736004)(106356001)(186003)(7696005)(305945005)(110136005)(66066001)(55016002)(53546011)(45080400002)(229853002)(105586002)(68736007)(93886005)(966005)(4326008)(6116002)(3846002)(5890100001)(6636002)(5250100002)(2900100001)(14454004)(5660300001)(33656002)(478600001)(6246003)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR0402MB3330; H:AM0PR0402MB3842.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 273aa3b0-ce7e-4e75-f161-08d5673bfad4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:AM0PR0402MB3330; x-ms-traffictypediagnostic: AM0PR0402MB3330: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(189930954265078)(185117386973197)(45079756050767)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231101)(944501161)(3002001)(10201501046)(6055026)(6041288)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM0PR0402MB3330; BCL:0; PCL:0; RULEID:; SRVR:AM0PR0402MB3330; x-forefront-prvs: 0567A15835 received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: CPBkR9yhWxgrIECmyZMArnuZ/O7GJxhf3tVFsnRRt2XC2fUQgHHvmbGG3AXaPV1V2qwVutKwwPRG4mkATsBfwA== 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: 273aa3b0-ce7e-4e75-f161-08d5673bfad4 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2018 17:16:05.0846 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0402MB3330 Subject: Re: [dpdk-dev] [RFC v3 1/1] lib: add compressdev 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, 29 Jan 2018 17:16:09 -0000 On 1/29/2018 7:26 AM, Verma, Shally wrote:=0A= > Hi=0A= >=0A= >> -----Original Message-----=0A= >> From: Trahe, Fiona [mailto:fiona.trahe@intel.com]=0A= >> Sent: 26 January 2018 00:13=0A= >> To: Verma, Shally ; Ahmed Mansour=0A= >> ; dev@dpdk.org; Akhil Goyal=0A= >> =0A= >> Cc: Challa, Mahipal ; Athreya, Narayana=0A= >> Prasad ; De Lara Guarch, Pablo=0A= >> ; Gupta, Ashish=0A= >> ; Sahu, Sunila ;=0A= >> Jain, Deepak K ; Hemant Agrawal=0A= >> ; Roy Pledge ; Youri=0A= >> Querry ; Trahe, Fiona =0A= >> Subject: RE: [RFC v3 1/1] lib: add compressdev API=0A= >>=0A= >> Hi Shally, Ahmed,=0A= >>=0A= >>=0A= >>> -----Original Message-----=0A= >>> From: Verma, Shally [mailto:Shally.Verma@cavium.com]=0A= >>> Sent: Thursday, January 25, 2018 10:25 AM=0A= >>> To: Ahmed Mansour ; Trahe, Fiona=0A= >> ;=0A= >>> dev@dpdk.org; Akhil Goyal =0A= >>> Cc: Challa, Mahipal ; Athreya, Narayana=0A= >> Prasad=0A= >>> ; De Lara Guarch, Pablo=0A= >> ;=0A= >>> Gupta, Ashish ; Sahu, Sunila=0A= >> ; Jain, Deepak K=0A= >>> ; Hemant Agrawal=0A= >> ; Roy Pledge=0A= >>> ; Youri Querry =0A= >>> Subject: RE: [RFC v3 1/1] lib: add compressdev API=0A= >>>=0A= >>>=0A= >>>=0A= >>>> -----Original Message-----=0A= >>>> From: Ahmed Mansour [mailto:ahmed.mansour@nxp.com]=0A= >>>> Sent: 25 January 2018 01:06=0A= >>>> To: Verma, Shally ; Trahe, Fiona=0A= >>>> ; dev@dpdk.org; Akhil Goyal=0A= >>>> =0A= >>>> Cc: Challa, Mahipal ; Athreya, Narayana=0A= >>>> Prasad ; De Lara Guarch, Pablo=0A= >>>> ; Gupta, Ashish=0A= >>>> ; Sahu, Sunila ;=0A= >>>> Jain, Deepak K ; Hemant Agrawal=0A= >>>> ; Roy Pledge ; Youri=0A= >>>> Querry =0A= >>>> Subject: Re: [RFC v3 1/1] lib: add compressdev API=0A= >>>>=0A= >>>> Hi All,=0A= >>>>=0A= >>>> Please see responses in line.=0A= >>>>=0A= >>>> Thanks,=0A= >>>>=0A= >>>> Ahmed=0A= >>>>=0A= >>>> On 1/23/2018 6:58 AM, Verma, Shally wrote:=0A= >>>>> Hi Fiona=0A= >>>>>=0A= >>>>>> -----Original Message-----=0A= >>>>>> From: Trahe, Fiona [mailto:fiona.trahe@intel.com]=0A= >>>>>> Sent: 19 January 2018 17:30=0A= >>>>>> To: Verma, Shally ; dev@dpdk.org;=0A= >>>>>> akhil.goyal@nxp.com=0A= >>>>>> Cc: Challa, Mahipal ; Athreya, Narayana= =0A= >>>>>> Prasad ; De Lara Guarch,=0A= >> Pablo=0A= >>>>>> ; Gupta, Ashish=0A= >>>>>> ; Sahu, Sunila=0A= >> ;=0A= >>>>>> Jain, Deepak K ; Hemant Agrawal=0A= >>>>>> ; Roy Pledge ;=0A= >> Youri=0A= >>>>>> Querry ; Ahmed Mansour=0A= >>>>>> ; Trahe, Fiona =0A= >>>>>> Subject: RE: [RFC v3 1/1] lib: add compressdev API=0A= >>>>>>=0A= >>>>>> Hi Shally,=0A= >>>>>>=0A= >>>>>>> -----Original Message-----=0A= >>>>>>> From: Verma, Shally [mailto:Shally.Verma@cavium.com]=0A= >>>>>>> Sent: Thursday, January 18, 2018 12:54 PM=0A= >>>>>>> To: Trahe, Fiona ; dev@dpdk.org=0A= >>>>>>> Cc: Challa, Mahipal ; Athreya,=0A= >> Narayana=0A= >>>>>> Prasad=0A= >>>>>>> ; De Lara Guarch, Pablo=0A= >>>>>> ;=0A= >>>>>>> Gupta, Ashish ; Sahu, Sunila=0A= >>>>>> ; Jain, Deepak K=0A= >>>>>>> ; Hemant Agrawal=0A= >>>>>> ; Roy Pledge=0A= >>>>>>> ; Youri Querry ;=0A= >>>>>> Ahmed Mansour=0A= >>>>>>> =0A= >>>>>>> Subject: RE: [RFC v3 1/1] lib: add compressdev API=0A= >>>>>>>=0A= >>>>>>> Hi Fiona=0A= >>>>>>>=0A= >>>>>>> While revisiting this, we identified few questions and additions.= =0A= >> Please=0A= >>>> see=0A= >>>>>> them inline.=0A= >>>>>>>> -----Original Message-----=0A= >>>>>>>> From: Trahe, Fiona [mailto:fiona.trahe@intel.com]=0A= >>>>>>>> Sent: 15 December 2017 23:19=0A= >>>>>>>> To: dev@dpdk.org; Verma, Shally =0A= >>>>>>>> Cc: Challa, Mahipal ; Athreya,=0A= >> Narayana=0A= >>>>>>>> Prasad ;=0A= >>>>>>>> pablo.de.lara.guarch@intel.com; fiona.trahe@intel.com=0A= >>>>>>>> Subject: [RFC v3 1/1] lib: add compressdev API=0A= >>>>>>>>=0A= >>>>>>>> Signed-off-by: Trahe, Fiona =0A= >>>>>>>> ---=0A= >>>>>>> //snip=0A= >>>>>>>=0A= >>>>>>>> +=0A= >>>>>>>> +int=0A= >>>>>>>> +rte_compressdev_queue_pair_setup(uint8_t dev_id, uint16_t=0A= >>>>>>>> queue_pair_id,=0A= >>>>>>>> + uint32_t max_inflight_ops, int socket_id)=0A= >>>>>>> [Shally] Is max_inflights_ops different from nb_streams_per_qp in= =0A= >>>> struct=0A= >>>>>> rte_compressdev_info?=0A= >>>>>>> I assume they both carry same purpose. If yes, then it will be bett= er=0A= >> to=0A= >>>> use=0A= >>>>>> single naming convention to=0A= >>>>>>> avoid confusion.=0A= >>>>>> [Fiona] No, I think they have different purposes.=0A= >>>>>> max_inflight_ops should be used to configure the qp with the number= =0A= >> of=0A= >>>> ops=0A= >>>>>> the application expects to be able to submit to the qp before it nee= ds=0A= >> to=0A= >>>> poll=0A= >>>>>> for a response. It can be configured differently for each qp. In the= QAT=0A= >>>> case it=0A= >>>>>> dictates the depth of the qp created, it may have different=0A= >> implications on=0A= >>>>>> other PMDs.=0A= >>>>>> nb_sessions_per_qp and nb_streams_per_qp are limitations the=0A= >> devices=0A= >>>>>> reports and are same for all qps on the device. QAT doesn't have=0A= >> those=0A= >>>>>> limitations and so would report 0, however I assumed they may be=0A= >>>> necessary=0A= >>>>>> for other devices.=0A= >>>>>> This assumption is based on the patch submitted by NXP to cryptodev= =0A= >> in=0A= >>>> Feb=0A= >>>>>> 2017=0A= >>>>>>=0A= >> https://emea01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fdpd= =0A= >>>> k.org%2Fml%2Farchives%2Fdev%2F2017-=0A= >>>>=0A= >> March%2F060740.html&data=3D02%7C01%7Cahmed.mansour%40nxp.com%7C=0A= >> b012d74d7530493b155108d56258955f%7C686ea1d3bc2b4c6fa92cd99c5c30163=0A= >> 5%7C0%7C0%7C636523054981379413&sdata=3D2SazlEazMxcBGS7R58CpNrX0G5=0A= >>>> OeWx8PLMwf%2FYzqv34%3D&reserved=3D0=0A= >>>>>> I also assume these are not necessarily the max number of sessions i= n=0A= >> ops=0A= >>>> on=0A= >>>>>> the qp at a given time, but the total number attached, i.e. if the d= evice=0A= >>>> has=0A= >>>>>> this limitation then sessions must be attached to qps, and presumabl= y=0A= >>>>>> reserve some resources. Being attached doesn't imply there is an op= =0A= >> on=0A= >>>> the=0A= >>>>>> qp at that time using that session. So it's not to relating to the i= nflight=0A= >> op=0A= >>>>>> count, but to the number of sessions attached/detached to the qp.=0A= >>>>>> Including Akhil on the To list, maybe NXP can confirm if these param= s=0A= >> are=0A= >>>>>> needed.=0A= >>>>> [Shally] Ok. Then let's wait for NXP to confirm on this requirement a= s=0A= >>>> currently spec doesn't have any API to attach=0A= >>>> queue_pair_to_specific_session_or_stream as cryptodev.=0A= >>>>> But then how application could know limit on max_inflight_ops=0A= >> supported=0A= >>>> on a qp? As it can pass any random number during qp_setup().=0A= >>>>> Do you believe we need to add a capability field in dev_info to indic= ate=0A= >> limit=0A= >>>> on max_inflight_ops?=0A= >>>>> Thanks=0A= >>>>> Shally=0A= >>>> [Ahmed] @Fiona This looks ok. max_inflight_ops makes sense. I=0A= >> understand=0A= >>>> it as a push back mechanism per qp. We do not have physical limit for= =0A= >>>> number of streams or sessions on a qp in our hardware, so we would=0A= >>>> return 0 here as well.=0A= >>>> @Shally in our PMD implementation we do not attach streams or sessions= =0A= >>>> to a particular qp. Regarding max_inflight_ops. I think that limit=0A= >>> [Shally] Ok. We too don't have any such limit defined. So, if these are= =0A= >> redundant fields then can be=0A= >>> removed until requirement is identified in context of compressdev.=0A= >> [Fiona] Ok, so it seems we're all agreed to remove max_nb_sessions_per_q= p=0A= >> and=0A= >> max_nb_streams_per_qp from rte_compressdev_info.=0A= >> I think we're also agreed to keep max_inflight_ops on the qp_setup.=0A= > [Shally] yes, by me.=0A= [Ahmed] That works.=0A= >=0A= >> It's not available on the info and if I understand you both correctly we= don't=0A= >> need to add it there as a hw limitation or capability. =0A= > [Shally] I'm fine with either ways. No preferences here currently.=0A= [Ahmed] Yes.=0A= >=0A= >> I'd expect the appl to set it to=0A= >> some value which is probably lower than any hardware limitation. The app= l=0A= >> may then=0A= >> perform many enqueue_bursts until the qp is full and if unable to enqueu= e a=0A= >> burst=0A= >> should try dequeueing to free up space on the qp for more enqueue_bursts= .=0A= > [Shally] qp not necessarily has to be full (depending upon PMD implementa= tion though) to run into this condition, especially when, say, Hw limit < a= pplication max_inflight_ops. =0A= > Thus, would rephrase it as:=0A= > "application may enqueue bursts up to limit setup in qp_setup and if enqu= eue_burst() returns with number < total nb_ops , then wait on dequeue to fr= ee-up space".=0A= [Ahmed] Agreed. The hard limit is left to the implementation.=0A= >=0A= >> I think the value it's set to can give the application some influence ov= er=0A= >> latency vs throughput.=0A= >> E.g. if it's set to a very large number then it allows the PMD to stockp= ile=0A= >> requests,=0A= >> which can result in longer latency, but optimal throughput as easier to = keep=0A= >> the=0A= >> engines supplied with requests. If set very small, latency may be short,= as=0A= >> requests get=0A= >> to engines sooner, but there's a risk of the engines running out of requ= ests=0A= >> if the PMD manages to process everything before the application tops up = the=0A= >> qp.=0A= > [Shally] I concur from you.=0A= [Ahmed] Makes sense.=0A= >=0A= >>>=0A= >>>> should be independent of hardware. Not all enqueues must succeed.=0A= >> The=0A= >>>> hardware can push back against the enqueuer dynamically if the=0A= >> resources=0A= >>>> needed to accommodate additional ops are not available yet. This push= =0A= >>>> back happens in the software if the user sets a max_inflight_ops that = is=0A= >>>> less that the hardware max_inflight_ops. The same return pathway can= =0A= >> be=0A= >>>> exercised if the user actually attempts to enqueue more than the=0A= >>>> supported max_inflight_ops because of the hardware.=0A= >>> [Shally] Ok. This sounds fine to me. As you mentioned, we can let=0A= >> application setup a queue pair with=0A= >>> any max_inflight_ops and, during enqueue_burst(), leave it on hardware= =0A= >> to consume as much as it can=0A= >>> subject to the limit set in qp_setup().=0A= >>> So, this doesn't seem to be a hard requirement on dev_info to expose.= =0A= >> Only knock-on effect I see is,=0A= >>> same testcase can then behave differently with different PMDs as each= =0A= >> PMD may have different support=0A= >>> level for same max_inflight_ops in their qp_setup().=0A= >=0A= =0A=