From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7BB02A04B1; Wed, 23 Sep 2020 15:37:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 605DA1DC36; Wed, 23 Sep 2020 15:37:45 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 33C6D1D8FC for ; Wed, 23 Sep 2020 15:37:43 +0200 (CEST) IronPort-SDR: IUHjpn7JGf3KtTgnntsy0F8ZQ4sgQY4WrhZ+UdxcboTQC5Lw8oywnnX7yqYNyPCSBJT/x417Qf UPrzIfkiYv4w== X-IronPort-AV: E=McAfee;i="6000,8403,9752"; a="161821770" X-IronPort-AV: E=Sophos;i="5.77,293,1596524400"; d="scan'208";a="161821770" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2020 06:37:42 -0700 IronPort-SDR: LVJK5YSER5/UmcGDWAUXuI33foJ6x5FSHvc6cvkD1+dZUNAEuBCsP8n6dYYeV67AAwkcPNlBCW ac2dFIQAB+zw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,293,1596524400"; d="scan'208";a="291680897" Received: from orsmsx606.amr.corp.intel.com ([10.22.229.19]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2020 06:37:41 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 23 Sep 2020 06:37:41 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 23 Sep 2020 06:37:41 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 23 Sep 2020 06:37:41 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.173) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Wed, 23 Sep 2020 06:37:38 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RFd5l+1JMr+/lupTQNYBlQ9wg5wMhWI2iSaHh580cwRkCELI+RXAIgL9k7PNvIfCnmTvF5uEjZOTGOm1AExv4676AFoL7ztKzoYgCl7ss0BJGpmw8h2pnSfdseJmD8QnRJQOmKbMZtjUx+4NyJNsctOMbUiozsoCu1aDMHM1TwEanMBXaZxuGpaD0+IBXwpbTDRBLVQXtn9CShVjlrMauiTe1VnFzOrmF5NhZcHKp+XHpTPk3uRZj+1C/uML4Z2g0Sq0iXFIzLVowfm77LU+AUEh0tJlwQVoCz37qcwa8ZXwoB2qSVOulBxhOWP1GRg5f32zMtpJNtWX2NqKwl6ZXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZROedOYWB6KxGNaeBR/gL6YII2nkPMgptsfYSE3SA58=; b=ZfXPrag7K+ad6X4UnWMJ2L5/ui/rY0L5ephwTB7TBOKda1ARWxBMITKYzxW3lucLh91CzRoxBSv0j2igXM89RdQIY+i8VfvFau2EavP8mYBSs8v6PZyaGHIDUPCnYrad7xMvLlZ5uTnHY73HBWqbAmi1v/WQrOCkOWFWrGtMcQeLPY7a8iNyRuAUHSpADUrONvOJa9F13PZP/oEJc0+DokCXfp5jGkENWEKStIwuOjfH9Ah6+YEW0/O+oyP9dhmxxCudt89+mGtwfCjyumOG6ZO0q/xYr4uvq3pRBqpYfVBj1yDVaJpPlKF/eapdFaPcmwB1f4XtXvKilGBjm6/aQQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZROedOYWB6KxGNaeBR/gL6YII2nkPMgptsfYSE3SA58=; b=KAhEPOIROeA6qr+gTLvpJPJhay4GfMyVoO8RYG4yU6FLw77XWHiPbeXRa2P0ArqV6xq6J+5sDplKsMzsfssEYYTcEPxmexAzhzm0Yu4NxD8lRGQ0GQOp3OAZeDxAoR0QeD8jfGhlKwe9lMUNubGf9UbBqDhaa5Tev0RRZYrDOls= Received: from BL0PR11MB3043.namprd11.prod.outlook.com (2603:10b6:208:33::19) by BL0PR11MB3506.namprd11.prod.outlook.com (2603:10b6:208:31::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Wed, 23 Sep 2020 13:37:36 +0000 Received: from BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::11fa:a7fe:329d:9239]) by BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::11fa:a7fe:329d:9239%5]) with mapi id 15.20.3391.027; Wed, 23 Sep 2020 13:37:36 +0000 From: "Zhang, Roy Fan" To: Akhil Goyal , "dev@dpdk.org" CC: "Trahe, Fiona" , "Kusztal, ArkadiuszX" , "Dybkowski, AdamX" , Anoob Joseph Thread-Topic: [dpdk-dev v9 4/4] doc: add cryptodev service APIs guide Thread-Index: AQHWhbweiYo7E6UpO0WHhA+t0mS6Oalu7AQAgAdd1JA= Date: Wed, 23 Sep 2020 13:37:36 +0000 Message-ID: References: <20200904152539.20608-1-roy.fan.zhang@intel.com> <20200908084253.81022-1-roy.fan.zhang@intel.com> <20200908084253.81022-5-roy.fan.zhang@intel.com> In-Reply-To: Accept-Language: zh-Hans-HK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.5.1.3 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [95.44.220.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ddbaebc2-cf40-4cf0-922d-08d85fc5d58e x-ms-traffictypediagnostic: BL0PR11MB3506: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 01G7S7VawiIBI28zHCdvGZrKDDoRCrs9rAZh41Gk9UQpwaxY62RwkiavENIc54/LSlWgfUeDnSBGHTZTGhfFwdWGxoiSBKvkRBQfq2jSGS5hiES+1eYxquW6RaT8yjHTMPXTxokpBMoPw/T27qcJn4pWSxTAS8mwKP4kmlxBrLsajWDBoala/5clyjRhWVkfLgY2JpJEKiieoyDmCYEhdN0NYLhul1ScqfAuc3PB4sZICHXOxPJtL+xhCfIukuWc8s5TzI5AtJ1lEbnRrsPr18GTPAxacPiYqV1Dm4WwlXKN1bBVcsuD3+c38RFb5Q1jxK7ae+TwN2pkb4eEUMfdZg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3043.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(376002)(366004)(39860400002)(136003)(66556008)(86362001)(26005)(316002)(186003)(66446008)(64756008)(8936002)(6506007)(71200400001)(66476007)(478600001)(5660300002)(9686003)(54906003)(7696005)(76116006)(33656002)(8676002)(4326008)(83380400001)(2906002)(52536014)(55016002)(110136005)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: xvSeRoveUUfmOj3YBxTaWN+YI8FdfYj7ST9AeAeHIiXJMZ74Ic1hPviuxhgqWIyEeWVyog5xh7t3lbawwOLFrutKoGFdvrcopiA5reu779ZbFGIdE0LyW1sNG3TFkNuO83FAZEusPIRzv0H+aKjF6EC6sNonT4GVltxdXad4PxnHyWrkXOWM5Ya+kOdawu+uBOkJkLJ5VFEKXuK7MpqPAMsxcuzvSAPzjMBsQy/QK7hmYUIenZTb862tAdJGGEDKtsh6cSFyLFXVEqpyzIm7pNMFSeJ6e8/7K7MrKqpHqmYd234wU8dRz/QZ2L1dvWLlFuSiW3AXdmI6sJEvkReilI/t3j3W7XJhuZoOiDqjL5HDC4Nf3LQs8H/Mkwkvoaa56G3IU7JKgoojV5eVwjA89+URIz4IHbyF7jaUMPaJklao/36zj/QpZ1SXHfAkd0DoMFgY0IS1eA7fcQvEmTLGE4VvAdWhDc7xqi4f+FAOzmq3uXRyd/JWImJvsFbXvFiJu0xF1bYnXTS1RrMTxSJZgoUebvt6G3Ems0fQEbC0VjmlIdOgJoHyMFuE4TqScD6Szlk0r5Fd8NfO8X+dix1nzkPK3BFirLf6M/8T5/ZupW0tBl9L5JMRg/IhuefuF/q1Q+01QBqI9z3BRzryhciFOQ== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3043.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ddbaebc2-cf40-4cf0-922d-08d85fc5d58e X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2020 13:37:36.7482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6xgUbLEZyjy7W6OgorRFeZS0xBDE8F1eAHlz4yo7YzeGOUy8jpj+jT8knN0fZymTeCBKl7gKpq2kY06jusbRGQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3506 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [dpdk-dev v9 4/4] doc: add cryptodev service APIs guide 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Akhil > -----Original Message----- ...=20 > > + > > +Either enqueue functions will not command the crypto device to start > > processing > > +until ``rte_cryptodev_dp_submit_done`` function is called. Before then > the user > > +shall expect the driver only stores the necessory context data in the > > +``rte_crypto_dp_service_ctx`` buffer for the next enqueue operation. I= f > the > > user > > +wants to abandon the submitted operations, simply call > > +``rte_cryptodev_dp_configure_service`` function instead with the > parameter > > +``is_update`` set to 0. The driver will recover the service context da= ta to > > +the previous state. >=20 > Can you explain a use case where this is actually being used? This looks = fancy > but > Do we have this type of requirement in any protocol stacks/specifications= ? > I believe it to be an extra burden on the application writer if it is not= a > protocol requirement. >=20 I missed responding this one.=20 The requirement comes from cooping with VPP crypto framework. The reason for this feature is fill the gap of cryptodev enqueue and dequeu= e operations. If the user application/library uses the approach similar to " rte_crypto_s= ym_vec" (such as VPP vnet_crypto_async_frame_t) that clusters multiple cryp= to ops as a burst, the application requires enqueuing and dequeuing all ops= as a whole inside, or nothing.=20 It is very slow for rte_cryptodev_enqueue/dequeue_burst to achieve this tod= ay as the user has no control over how many ops I want to enqueue/dequeue p= reciously. For example I want to enqueue a " rte_crypto_sym_vec" buffer con= tains 32 descriptors, and stores " rte_crypto_sym_vec" as opaque data in en= queue, but rte_cryptodev_enqueue_burst returns 31, I have no option but ca= che the 1 left job for next enqueue attempt (or I manually check the inflig= ht count in every enqueue). Also during dequeue since the number "32" is st= ored inside rte_crypto_sym_vec.num, I have no way to know how many ops to = dequeue, but blindly dequeue them and store in a software ring, parse the t= he dequeue count from retrieved opaque data, and check the ring count again= st dequeue count.=20 With the new way provided we can easily achieve the goal. For HW crypto PMD= such implementation is relatively easy, we only need to create a shadow co= py to the queue pair data in ``rte_crypto_dp_service_ctx`` and updates in e= nqueue/dequeue, when "enqueue/dequeue_done" is called the queue is kicked t= o start processing jobs already set in the queue and merge the shadow copy= queue data into driver maintained one. Regards, Fan