From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0051.outbound.protection.outlook.com [104.47.32.51]) by dpdk.org (Postfix) with ESMTP id 59478A49F for ; Thu, 25 Jan 2018 11:24:59 +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=FFLpLpZTQrD+s0prCAe/cS95EDuhxUbDJWq+dkqMo/4=; b=gP89vGnk9WcJdZs2Wu4DrKCoUVfkcmEEbvYTYdmHmzZ5ZEZcBqtas9OTQESYs6CoXKA9lrQToPs6BjwvL1SlUm5fyOE+i09kQcnd43MMJvPgR8tdDnk3ZSKwqVVkHxG/0I9eQhNUfZUZ4y8boY9SCEXq3zLPcebwyGJOERNK8TY= Received: from BY1PR0701MB1111.namprd07.prod.outlook.com (10.160.104.21) by BLUPR0701MB1988.namprd07.prod.outlook.com (10.163.121.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Thu, 25 Jan 2018 10:24:56 +0000 Received: from BY1PR0701MB1111.namprd07.prod.outlook.com ([fe80::e040:3b79:6671:b66a]) by BY1PR0701MB1111.namprd07.prod.outlook.com ([fe80::e040:3b79:6671:b66a%14]) with mapi id 15.20.0428.019; Thu, 25 Jan 2018 10:24:54 +0000 From: "Verma, Shally" To: Ahmed Mansour , "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: AQHTdc0Olvrvx8Spo02l2PHMHF7TgqOEYOCw Date: Thu, 25 Jan 2018 10:24:54 +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> 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; BLUPR0701MB1988; 7:MBfXCN5n1flMIyz8zp+QDDnVl4cerBAxe3Nc52J6DwOiI+dVBZMAey6wA+UgIITyKvwC2pc/DN3aPE2yDQS8nm4/ErChXN7E119yNyu+nE6zle1N1KFPRDubGqamu2WzgqHRDhMC6p7wdtjq95AaEavEjZPf7GZDXFXk/aT/qSgqfD6IR5aWXh2fhMKcEOayWJw2PVtOFp5Pc+fBuqw3aj7M6PbGEinHLVeyllya7RrTonjN6XRI2a5B8UHr6dGO x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(396003)(376002)(39860400002)(366004)(346002)(39380400002)(51444003)(13464003)(53754006)(199004)(189003)(81156014)(8676002)(81166006)(229853002)(3660700001)(68736007)(8656006)(99286004)(3280700002)(5660300001)(97736004)(8936002)(2900100001)(9686003)(53936002)(54906003)(6306002)(575784001)(55016002)(86362001)(316002)(6436002)(110136005)(2950100002)(102836004)(25786009)(53546011)(7696005)(76176011)(966005)(6116002)(2906002)(55236004)(59450400001)(3846002)(2501003)(5890100001)(7736002)(105586002)(14454004)(305945005)(45080400002)(26005)(93886005)(478600001)(6246003)(4326008)(186003)(5250100002)(72206003)(6506007)(33656002)(106356001)(74316002)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1988; H:BY1PR0701MB1111.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: fc531150-f0b0-4efd-e7f3-08d563dde072 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BLUPR0701MB1988; x-ms-traffictypediagnostic: BLUPR0701MB1988: 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)(3002001)(93006095)(93001095)(10201501046)(3231023)(2400081)(944501161)(6041288)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BLUPR0701MB1988; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0701MB1988; x-forefront-prvs: 0563F2E8B7 received-spf: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: +5djrjzrmKtEH+tQBLMFzo1YXvVtJ1Hqaiio9Tu9JYsnOzuiWMGRAUjL+QOGLDP8Rxp59SW4NrfzH8ogIKnC/A== 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: fc531150-f0b0-4efd-e7f3-08d563dde072 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2018 10:24:54.5936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1988 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: Thu, 25 Jan 2018 10:24:59 -0000 > -----Original Message----- > From: Ahmed Mansour [mailto:ahmed.mansour@nxp.com] > Sent: 25 January 2018 01:06 > 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 > Subject: Re: [RFC v3 1/1] lib: add compressdev API >=20 > Hi All, >=20 > Please see responses in line. >=20 > Thanks, >=20 > Ahmed >=20 > On 1/23/2018 6:58 AM, Verma, Shally wrote: > > Hi Fiona > > > >> -----Original Message----- > >> From: Trahe, Fiona [mailto:fiona.trahe@intel.com] > >> Sent: 19 January 2018 17:30 > >> To: Verma, Shally ; dev@dpdk.org; > >> akhil.goyal@nxp.com > >> Cc: Challa, Mahipal ; Athreya, Narayana > >> Prasad ; De Lara Guarch, Pablo > >> ; Gupta, Ashish > >> ; Sahu, Sunila ; > >> Jain, Deepak K ; Hemant Agrawal > >> ; Roy Pledge ; Youri > >> Querry ; Ahmed Mansour > >> ; Trahe, Fiona > >> Subject: RE: [RFC v3 1/1] lib: add compressdev API > >> > >> Hi Shally, > >> > >>> -----Original Message----- > >>> From: Verma, Shally [mailto:Shally.Verma@cavium.com] > >>> Sent: Thursday, January 18, 2018 12:54 PM > >>> To: Trahe, Fiona ; dev@dpdk.org > >>> Cc: Challa, Mahipal ; Athreya, Narayana > >> Prasad > >>> ; De Lara Guarch, Pablo > >> ; > >>> Gupta, Ashish ; Sahu, Sunila > >> ; Jain, Deepak K > >>> ; Hemant Agrawal > >> ; Roy Pledge > >>> ; Youri Querry ; > >> Ahmed Mansour > >>> > >>> Subject: RE: [RFC v3 1/1] lib: add compressdev API > >>> > >>> Hi Fiona > >>> > >>> While revisiting this, we identified few questions and additions. Ple= ase > see > >> them inline. > >>> > >>>> -----Original Message----- > >>>> From: Trahe, Fiona [mailto:fiona.trahe@intel.com] > >>>> Sent: 15 December 2017 23:19 > >>>> To: dev@dpdk.org; Verma, Shally > >>>> Cc: Challa, Mahipal ; Athreya, Narayana > >>>> Prasad ; > >>>> pablo.de.lara.guarch@intel.com; fiona.trahe@intel.com > >>>> Subject: [RFC v3 1/1] lib: add compressdev API > >>>> > >>>> Signed-off-by: Trahe, Fiona > >>>> --- > >>> //snip > >>> > >>>> + > >>>> +int > >>>> +rte_compressdev_queue_pair_setup(uint8_t dev_id, uint16_t > >>>> queue_pair_id, > >>>> + uint32_t max_inflight_ops, int socket_id) > >>> [Shally] Is max_inflights_ops different from nb_streams_per_qp in > struct > >> rte_compressdev_info? > >>> I assume they both carry same purpose. If yes, then it will be better= to > use > >> single naming convention to > >>> avoid confusion. > >> [Fiona] No, I think they have different purposes. > >> max_inflight_ops should be used to configure the qp with the number of > ops > >> the application expects to be able to submit to the qp before it needs= to > poll > >> for a response. It can be configured differently for each qp. In the Q= AT > case it > >> dictates the depth of the qp created, it may have different implicatio= ns on > >> other PMDs. > >> nb_sessions_per_qp and nb_streams_per_qp are limitations the devices > >> reports and are same for all qps on the device. QAT doesn't have those > >> limitations and so would report 0, however I assumed they may be > necessary > >> for other devices. > >> This assumption is based on the patch submitted by NXP to cryptodev in > Feb > >> 2017 > >> > https://emea01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fdpd > k.org%2Fml%2Farchives%2Fdev%2F2017- > March%2F060740.html&data=3D02%7C01%7Cahmed.mansour%40nxp.com%7C > b012d74d7530493b155108d56258955f%7C686ea1d3bc2b4c6fa92cd99c5c30163 > 5%7C0%7C0%7C636523054981379413&sdata=3D2SazlEazMxcBGS7R58CpNrX0G5 > OeWx8PLMwf%2FYzqv34%3D&reserved=3D0 > >> I also assume these are not necessarily the max number of sessions in = ops > on > >> the qp at a given time, but the total number attached, i.e. if the dev= ice > has > >> this limitation then sessions must be attached to qps, and presumably > >> reserve some resources. Being attached doesn't imply there is an op on > the > >> qp at that time using that session. So it's not to relating to the inf= light op > >> count, but to the number of sessions attached/detached to the qp. > >> Including Akhil on the To list, maybe NXP can confirm if these params = are > >> needed. > > [Shally] Ok. Then let's wait for NXP to confirm on this requirement as > currently spec doesn't have any API to attach > queue_pair_to_specific_session_or_stream as cryptodev. > > > > But then how application could know limit on max_inflight_ops supported > on a qp? As it can pass any random number during qp_setup(). > > Do you believe we need to add a capability field in dev_info to indicat= e limit > on max_inflight_ops? > > > > Thanks > > Shally > [Ahmed] @Fiona This looks ok. max_inflight_ops makes sense. I understand > it as a push back mechanism per qp. We do not have physical limit for > number of streams or sessions on a qp in our hardware, so we would > return 0 here as well. > @Shally in our PMD implementation we do not attach streams or sessions > to a particular qp. Regarding max_inflight_ops. I think that limit [Shally] Ok. We too don't have any such limit defined. So, if these are red= undant fields then can be removed until requirement is identified in contex= t of compressdev. > should be independent of hardware. Not all enqueues must succeed. The > hardware can push back against the enqueuer dynamically if the resources > needed to accommodate additional ops are not available yet. This push > back happens in the software if the user sets a max_inflight_ops that is > less that the hardware max_inflight_ops. The same return pathway can be > exercised if the user actually attempts to enqueue more than the > supported max_inflight_ops because of the hardware. [Shally] Ok. This sounds fine to me. As you mentioned, we can let applicati= on setup a queue pair with any max_inflight_ops and, during enqueue_burst()= , leave it on hardware to consume as much as it can subject to the limit se= t in qp_setup(). So, this doesn't seem to be a hard requirement on dev_info to expose. Only = knock-on effect I see is, same testcase can then behave differently with di= fferent PMDs as each PMD may have different support level for same max_infl= ight_ops in their qp_setup(). > >> > >>> Also, is it optional API? Like Is this a valid use case?: > >>> dev_configure() --> dev_start() --> qp_start() --> enqueue/dequeue() = -- > > > >> qp_stop() --> dev_stop() --> > >>> dev_close()? > >> [Fiona] I don't think it should be optional as some PMDs need to alloc= ate > >> resources based on the setup data passed in on this API. > >> > >>> //snip > >>> > >>>> + > >>>> +#define RTE_COMPRESSDEV_PMD_NAME_ARG > >>>> ("name") > >>>> +#define RTE_COMPRESSDEV_PMD_MAX_NB_QP_ARG > >>>> ("max_nb_queue_pairs") > >>>> +#define RTE_COMPRESSDEV_PMD_SOCKET_ID_ARG > >> ("socket_id") > >>>> + > >>> [Shally] Need to define argument macro for max_nb_session_per_qp > and > >> max_nb_streams_per_qp as > >>> well > >> [Fiona] ok > >> > >>>> + > >>>> +static const char * const compressdev_pmd_valid_params[] =3D { > >>>> + RTE_COMPRESSDEV_PMD_NAME_ARG, > >>>> + RTE_COMPRESSDEV_PMD_MAX_NB_QP_ARG, > >>>> + RTE_COMPRESSDEV_PMD_SOCKET_ID_ARG > >>>> +}; > >>> [Shally] Likewise, array need to be updated with other mentioned two > >> arguments > >> Fiona] ok > >> > >> > >>>> + > >>>> +/** > >>>> + * @internal > >>>> + * Initialisation parameters for comp devices > >>>> + */ > >>>> +struct rte_compressdev_pmd_init_params { > >>>> + char name[RTE_COMPRESSDEV_NAME_MAX_LEN]; > >>>> + size_t private_data_size; > >>>> + int socket_id; > >>>> + unsigned int max_nb_queue_pairs; > >>> [Shally] And this also need to be updated with > max_nb_sessions_per_qp > >> and max_streams_per_qp > >> [Fiona] ok > >> > >>> //snip > >>> > >>> Thanks > >>> Shally >=20