From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0052.outbound.protection.outlook.com [104.47.0.52]) by dpdk.org (Postfix) with ESMTP id 7CABA23B for ; Wed, 24 Jan 2018 20:36:18 +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=TN2DhwwGyFN9BOCXwHWi8gfrWbP5qRLMA8c9ZY8YqX0=; b=U9hu5Ho+Yn4bnlbM7hieIjzLiUVsi0VadjNyqPpA3ndvCONfdsjkuP+xbNbR5ulEqVXNbISwh9eFLNOgOvVsVH7l4YzljeVTCnSvJiBVOGuw5RE2B9pu8bglxdGR9Q+obdtE8pa4Vp92/f5Dz7Ri1Af/HoOdPvQZGff9YUookvY= Received: from VI1PR0402MB3853.eurprd04.prod.outlook.com (52.134.16.149) by VI1PR0402MB2861.eurprd04.prod.outlook.com (10.175.23.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Wed, 24 Jan 2018 19:36:15 +0000 Received: from VI1PR0402MB3853.eurprd04.prod.outlook.com ([fe80::6469:240a:79d1:fb90]) by VI1PR0402MB3853.eurprd04.prod.outlook.com ([fe80::6469:240a:79d1:fb90%13]) with mapi id 15.20.0428.019; Wed, 24 Jan 2018 19:36:14 +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: Wed, 24 Jan 2018 19:36:14 +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> 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; VI1PR0402MB2861; 7:/rqGPzGfUove3iqEHLlDBFyIefsU+L3NaiGIo5DCQSKPRC6vSRkw7XPunkcitYwNTEfJTJxsA2wqVWrkX1NlCEDyQnH6EGNy/oL18nr2rpRUTnP7U4FKVTyNYt67zdo773nLuyj00mhyFeQLdnrNLkfZdUcIMHTfPz+Bq0V6+p8FU/qmM0ChvICJ62TUB6fucgspZUkx/RCFKpKCumbF04PJlizuJ/5gh4X1aqUxnKNxLrtc1x7b1fmydk/THlm1 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(396003)(366004)(39380400002)(39860400002)(346002)(376002)(199004)(189003)(51444003)(13464003)(53754006)(2900100001)(59450400001)(25786009)(6506007)(575784001)(6636002)(55016002)(99286004)(86362001)(229853002)(305945005)(76176011)(6436002)(74316002)(3846002)(5250100002)(7736002)(7696005)(6116002)(6246003)(68736007)(2501003)(3660700001)(5890100001)(8676002)(106356001)(33656002)(3280700002)(97736004)(81166006)(5660300001)(4326008)(316002)(2906002)(53936002)(105586002)(110136005)(81156014)(54906003)(26005)(102836004)(9686003)(93886005)(966005)(478600001)(53546011)(6306002)(45080400002)(8936002)(14454004)(66066001)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0402MB2861; H:VI1PR0402MB3853.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: 5f84d448-883b-4bf9-a814-08d56361bb18 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:VI1PR0402MB2861; x-ms-traffictypediagnostic: VI1PR0402MB2861: 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)(8121501046)(5005006)(3231023)(2400081)(944501161)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0402MB2861; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0402MB2861; x-forefront-prvs: 056297E276 received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: eaLsUiQ6KBBlnjcme04ECGt3FewUhc1Rlmy9DA+FiS51mEnDYxKNsy3g4z0Ta+3Emqaqwti0uiJ4A5uTJl6ZiQ== 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: 5f84d448-883b-4bf9-a814-08d56361bb18 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 19:36:14.3319 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0402MB2861 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: Wed, 24 Jan 2018 19:36:18 -0000 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, Pablo=0A= >> ; Gupta, Ashish=0A= >> ; Sahu, Sunila ;=0A= >> Jain, Deepak K ; Hemant Agrawal=0A= >> ; Roy Pledge ; 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, 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. Pleas= e see=0A= >> them inline.=0A= >>>=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, 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 struc= t=0A= >> rte_compressdev_info?=0A= >>> I assume they both carry same purpose. If yes, then it will be better t= o 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 of o= ps=0A= >> the application expects to be able to submit to the qp before it needs t= o poll=0A= >> for a response. It can be configured differently for each qp. In the QAT= case it=0A= >> dictates the depth of the qp created, it may have different implications= on=0A= >> other PMDs.=0A= >> nb_sessions_per_qp and nb_streams_per_qp are limitations the devices=0A= >> reports and are same for all qps on the device. QAT doesn't have those= =0A= >> limitations and so would report 0, however I assumed they may be necessa= ry=0A= >> for other devices.=0A= >> This assumption is based on the patch submitted by NXP to cryptodev in F= eb=0A= >> 2017=0A= >> https://emea01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fdpd= k.org%2Fml%2Farchives%2Fdev%2F2017-March%2F060740.html&data=3D02%7C01%7Cahm= ed.mansour%40nxp.com%7Cb012d74d7530493b155108d56258955f%7C686ea1d3bc2b4c6fa= 92cd99c5c301635%7C0%7C0%7C636523054981379413&sdata=3D2SazlEazMxcBGS7R58CpNr= X0G5OeWx8PLMwf%2FYzqv34%3D&reserved=3D0=0A= >> I also assume these are not necessarily the max number of sessions in op= s on=0A= >> the qp at a given time, but the total number attached, i.e. if the devic= e has=0A= >> this limitation then sessions must be attached to qps, and presumably=0A= >> reserve some resources. Being attached doesn't imply there is an op on t= he=0A= >> qp at that time using that session. So it's not to relating to the infli= ght 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 params ar= e=0A= >> needed.=0A= > [Shally] Ok. Then let's wait for NXP to confirm on this requirement as cu= rrently spec doesn't have any API to attach queue_pair_to_specific_session_= or_stream as cryptodev.=0A= >=0A= > But then how application could know limit on max_inflight_ops supported o= n 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 indicate = limit on max_inflight_ops?=0A= >=0A= > Thanks=0A= > Shally=0A= [Ahmed] @Fiona This looks ok. max_inflight_ops makes sense. I 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= should be independent of hardware. Not all enqueues must succeed. The=0A= hardware can push back against the enqueuer dynamically if the 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 be=0A= exercised if the user actually attempts to enqueue more than the=0A= supported max_inflight_ops because of the hardware.=0A= >>=0A= >>> Also, is it optional API? Like Is this a valid use case?:=0A= >>> dev_configure() --> dev_start() --> qp_start() --> enqueue/dequeue() --= >=0A= >> qp_stop() --> dev_stop() -->=0A= >>> dev_close()?=0A= >> [Fiona] I don't think it should be optional as some PMDs need to allocat= e=0A= >> resources based on the setup data passed in on this API.=0A= >>=0A= >>> //snip=0A= >>>=0A= >>>> +=0A= >>>> +#define RTE_COMPRESSDEV_PMD_NAME_ARG=0A= >>>> ("name")=0A= >>>> +#define RTE_COMPRESSDEV_PMD_MAX_NB_QP_ARG=0A= >>>> ("max_nb_queue_pairs")=0A= >>>> +#define RTE_COMPRESSDEV_PMD_SOCKET_ID_ARG=0A= >> ("socket_id")=0A= >>>> +=0A= >>> [Shally] Need to define argument macro for max_nb_session_per_qp and=0A= >> max_nb_streams_per_qp as=0A= >>> well=0A= >> [Fiona] ok=0A= >>=0A= >>>> +=0A= >>>> +static const char * const compressdev_pmd_valid_params[] =3D {=0A= >>>> + RTE_COMPRESSDEV_PMD_NAME_ARG,=0A= >>>> + RTE_COMPRESSDEV_PMD_MAX_NB_QP_ARG,=0A= >>>> + RTE_COMPRESSDEV_PMD_SOCKET_ID_ARG=0A= >>>> +};=0A= >>> [Shally] Likewise, array need to be updated with other mentioned two=0A= >> arguments=0A= >> Fiona] ok=0A= >>=0A= >>=0A= >>>> +=0A= >>>> +/**=0A= >>>> + * @internal=0A= >>>> + * Initialisation parameters for comp devices=0A= >>>> + */=0A= >>>> +struct rte_compressdev_pmd_init_params {=0A= >>>> + char name[RTE_COMPRESSDEV_NAME_MAX_LEN];=0A= >>>> + size_t private_data_size;=0A= >>>> + int socket_id;=0A= >>>> + unsigned int max_nb_queue_pairs;=0A= >>> [Shally] And this also need to be updated with max_nb_sessions_per_qp= =0A= >> and max_streams_per_qp=0A= >> [Fiona] ok=0A= >>=0A= >>> //snip=0A= >>>=0A= >>> Thanks=0A= >>> Shally=0A= =0A= =0A=