From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 6E0A0A00C5;
	Mon,  6 Jul 2020 12:02:32 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 410511DA43;
	Mon,  6 Jul 2020 12:02:32 +0200 (CEST)
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
 by dpdk.org (Postfix) with ESMTP id 20E231DA23
 for <dev@dpdk.org>; Mon,  6 Jul 2020 12:02:30 +0200 (CEST)
IronPort-SDR: 2YVjaoNyl05lLedXu0zbjgVxBFmLYBip11qPGl3lva1KcqXPe8AeyeYB+6lqNqslGOxo4wYA1z
 Yl6SZje7uxCg==
X-IronPort-AV: E=McAfee;i="6000,8403,9673"; a="146463965"
X-IronPort-AV: E=Sophos;i="5.75,318,1589266800"; d="scan'208";a="146463965"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga007.fm.intel.com ([10.253.24.52])
 by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 06 Jul 2020 03:02:30 -0700
IronPort-SDR: C9aylk1jbOrsXc+PQ5sEzJICoyeKprB+mZt9dGPSFLhtBhWvTo+MzwNQY5Gmj4IkF1XZunu4ry
 hlljojOjbKjQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.75,318,1589266800"; d="scan'208";a="266503679"
Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204])
 by fmsmga007.fm.intel.com with ESMTP; 06 Jul 2020 03:02:30 -0700
Received: from fmsmsx113.amr.corp.intel.com (10.18.116.7) by
 FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS)
 id 14.3.439.0; Mon, 6 Jul 2020 03:02:29 -0700
Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by
 FMSMSX113.amr.corp.intel.com (10.18.116.7) with Microsoft SMTP Server (TLS)
 id 14.3.439.0; Mon, 6 Jul 2020 03:02:29 -0700
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.168)
 by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id
 14.3.439.0; Mon, 6 Jul 2020 03:02:29 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=SgzLSQj9r3GQMkbwEHlCwD2heOEKFv6wWfZhBpNP933LQrEqABAKHTbumYumLPtYVacqHhyY9h/wW0keBJIqMB3f2rQOG7xYp97BjYDs067OdJvQsDO6ZBzDGqtt0J8u/J+DuB05pmP4RH4az3dcu1QafC838Kp8ffr0JFjhyZzi7E23nkrKxG/NshoMRMBobv2p/GTLYegNdflfX9lXLi4ZoixhjrmGXvVwplQeuQ9/P38hvQ7j4wXhQt+uhC4JFCmkAtMS7lUvEWxtpsq1JPckYnnkmcMTbu3THb2PuTsAgnIUn369+tAVxXVLSZ6AEBoU33yQcwAjfaaEasqzKg==
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=18UzK/oljMc6bNB707B3kbpymULYALeFWVD1sqffTF0=;
 b=eUE2I1BFbYCn7uV8k9vM24NQIpOg8xP2qVK/AzNL6Hcn9tUQ2+ACR+veFEK7ILeI7OEeOGbJzZgZFI9V0LsIXJdQ10s4au0uV7yzg8C5ch7whgHkXQL9h2MoC91s5ElyfWPjnpogkAnXdSse3RCXZhBiPfPTmj6rS9NCfaAna7CMgufS6r4YybcXURJxIkiU3VXTpbnVbRaQ3fovj1q1zdovHL2d2L3HUQXJ93ylxAXj13q1lo5FEH6WwOqorPVFckM1dKN9CjcID9+atzUxz+FkkX99us9CD0ExVVZVb0Ac++B3ZosshpOMVesm1m7kt5VlpPe/WPKS6GheHBSt4g==
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=18UzK/oljMc6bNB707B3kbpymULYALeFWVD1sqffTF0=;
 b=ecmYXO4CXlSUgX774yCfIzj8qUgHGYR0zkTqXAdOtDQ7XIJCdsunfkdCT6/qKq3m1Q1ywrzeuFekNbLRCRHl+HiTJozQS8hBraaWsOX3O/uQrffmg8va7b8STGvrNIMjRi1myRuqTL2Wl2yWYCstu9Ir90f0kKY0vXWR/4SjXNQ=
Received: from BL0PR11MB3043.namprd11.prod.outlook.com (2603:10b6:208:33::19)
 by BL0PR11MB3457.namprd11.prod.outlook.com (2603:10b6:208:64::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.27; Mon, 6 Jul
 2020 10:02:28 +0000
Received: from BL0PR11MB3043.namprd11.prod.outlook.com
 ([fe80::dd8e:7a6b:53ca:2a8a]) by BL0PR11MB3043.namprd11.prod.outlook.com
 ([fe80::dd8e:7a6b:53ca:2a8a%4]) with mapi id 15.20.3153.029; Mon, 6 Jul 2020
 10:02:27 +0000
From: "Zhang, Roy Fan" <roy.fan.zhang@intel.com>
To: Akhil Goyal <akhil.goyal@nxp.com>, "dev@dpdk.org" <dev@dpdk.org>,
 "anoobj@marvell.com" <anoobj@marvell.com>, "asomalap@amd.com"
 <asomalap@amd.com>, "ruifeng.wang@arm.com" <ruifeng.wang@arm.com>,
 Nagadheeraj Rottela <rnagadheeraj@marvell.com>, Michael Shamis
 <michaelsh@marvell.com>, Ankur Dwivedi <adwivedi@marvell.com>, Jay Zhou
 <jianjay.zhou@huawei.com>, "De Lara Guarch, Pablo"
 <pablo.de.lara.guarch@intel.com>
CC: "Trahe, Fiona" <fiona.trahe@intel.com>, "Bronowski, PiotrX"
 <piotrx.bronowski@intel.com>, "Ananyev, Konstantin"
 <konstantin.ananyev@intel.com>, Thomas Monjalon <thomas@monjalon.net>
Thread-Topic: [dpdk-dev v4 1/4] cryptodev: add symmetric crypto data-path APIs
Thread-Index: AQHWUTh9W23hQCo6PkeV7n4G/Cv9Iqj3u/CAgAKPEPA=
Date: Mon, 6 Jul 2020 10:02:27 +0000
Message-ID: <BL0PR11MB30438061A6C5275B004B4369B8690@BL0PR11MB3043.namprd11.prod.outlook.com>
References: <20200703110923.26452-1-roy.fan.zhang@intel.com>
 <20200703124942.29171-1-roy.fan.zhang@intel.com>
 <20200703124942.29171-2-roy.fan.zhang@intel.com>
 <VI1PR04MB316870AC08947B06B5F8C870E66B0@VI1PR04MB3168.eurprd04.prod.outlook.com>
In-Reply-To: <VI1PR04MB316870AC08947B06B5F8C870E66B0@VI1PR04MB3168.eurprd04.prod.outlook.com>
Accept-Language: zh-Hans-HK, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZGY1NWE5NGMtNTliYy00NjhlLWJmZTMtZmVjMDdmYTgzZmI3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiUm52UlVlR1wvTjdveUkxVllxUlY5b2d6ZkphSldnNm1zSjFBM3pva0hnVEZ1aGc3elN2Zm9HRjQrSTJ5SHpqNXoifQ==
x-ctpclassification: CTP_NT
dlp-version: 11.2.0.6
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: [192.198.151.171]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b99864e3-4f82-407b-f237-08d82193b09c
x-ms-traffictypediagnostic: BL0PR11MB3457:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BL0PR11MB3457D0FB52939511FE10BD9BB8690@BL0PR11MB3457.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04569283F9
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7sGZ3BcCuFpmB/Vl/+VFK13COELG+jXZQT0CmD1dzssXFOsXRnp/gCPWuyZMivGXh2f2Z1DUc1yuG6/bw2arKtwevWwdifkp3QAV/aDuXwkIn7L5sCkNj3z3Z6ZrzaZygA8ulGZdzA5hNuDBziUfKX6+TovsoxMmo1p2rJZSwIlWqRyFeh878eeupf8LQ712W2H6pA/DqMCFsARzrKvw1g4f4KES4BfC6zS3CKb/3UuiwwjjCb2iy0TlMcpfF1R/tMg1BRJ8EALJPGQxQyoJJJnefiZBY8xjZ67KB+ThrBWAovFlawr6WoOKtz8jRuIWZ7M5Sz0dYmJ3KhMXiZRDOTzzgSBVnTJZDZ2LpPZf6gQAQbnlwNBPnVFqn5gI7gBt
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;
 SFTY:;
 SFS:(4636009)(136003)(396003)(366004)(346002)(376002)(39860400002)(5660300002)(71200400001)(8676002)(6636002)(7696005)(186003)(316002)(19627235002)(4326008)(66476007)(66556008)(64756008)(66446008)(110136005)(54906003)(86362001)(26005)(53546011)(6506007)(52536014)(76116006)(8936002)(2906002)(83380400001)(66946007)(55016002)(33656002)(7416002)(478600001)(9686003)(921003);
 DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: uUNCke0d2q+oHwIpqpxv79CMuSa/OYNwhWDUySFV/dRrd2Aow4egwea2rSVAPW+XNe8ujaRp+pQoHjTbOaYWhUZxSaNQW2sMMgLD10nKgmNnekW9iJpiTiHa3xsZAdyYETZFVB7UMvRu4EVV0m4gip35c7iuO6C8CSj9wMelw4fNJuVMNh4tBCXZsyFNFfqICwbJ1PptWgD3TFMi2V7ADfwgOAIalwAWIfw677hsO4kJ0v5vwHRRqtfTOVUyRcSx+gRA5Msi5S576txzo6nTY8jfztRjF/jx05JwMB5V0xL9Hla5yUPeen9axceMy09rvebSvzebdSm7thT5ljSm8/JCQ3MCWNGiEPzkQ/MH04wgHoRYprEE+HFfeCkfsKa0KekqzVW4s28X5abufatQzRM66J81LUrpJOccjEPeDkHeLX1QRxtsIEIVoMABmKHd0nRgGloQFZlCeizbjmNYOFvScyTRmVjyw+6UUr2E+lUAAXV9E/0g3LWaXXbF09R0
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: b99864e3-4f82-407b-f237-08d82193b09c
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2020 10:02:27.8380 (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: iLcE1qfPUSyiJIwuHEih6rhbeXU6r1/2mLFNGEVg44r2OSPYuiYPYyJxpk0q+rDesuKZ1q3oDlA4YO4klqH8bA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3457
X-OriginatorOrg: intel.com
Subject: Re: [dpdk-dev] [dpdk-dev v4 1/4] cryptodev: add symmetric crypto
	data-path APIs
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi Akhil,

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Saturday, July 4, 2020 7:16 PM
> To: Zhang, Roy Fan <roy.fan.zhang@intel.com>; dev@dpdk.org;
> anoobj@marvell.com; asomalap@amd.com; ruifeng.wang@arm.com;
> Nagadheeraj Rottela <rnagadheeraj@marvell.com>; Michael Shamis
> <michaelsh@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>; Jay
> Zhou <jianjay.zhou@huawei.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Cc: Trahe, Fiona <fiona.trahe@intel.com>; Bronowski, PiotrX
> <piotrx.bronowski@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Subject: RE: [dpdk-dev v4 1/4] cryptodev: add symmetric crypto data-path
> APIs
>=20
> Hi Fan,
>=20
> > +
> > +/**
> > + * Asynchronous operation job descriptor.
> > + * Used by HW crypto devices direct API call that supports such activi=
ty
> > + **/
> > +struct rte_crypto_sym_job {
> > +	union {
> > +		/**
> > +		 * When RTE_CRYPTO_HW_ENQ_FLAG_IS_SGL bit is set in
> flags,
> > sgl
> > +		 * field is used as input data. Otherwise data_iova is
> > +		 * used.
> > +		 **/
> > +		rte_iova_t data_iova;
> > +		struct rte_crypto_sgl *sgl;
> > +	};
> > +	union {
> > +		/**
> > +		 * Different than cryptodev ops, all ofs and len fields have
> > +		 * the unit of bytes (including Snow3G/Kasumi/Zuc.
> > +		 **/
> > +		struct {
> > +			uint32_t cipher_ofs;
> > +			uint32_t cipher_len;
> > +		} cipher_only;
> > +		struct {
> > +			uint32_t auth_ofs;
> > +			uint32_t auth_len;
> > +			rte_iova_t digest_iova;
> > +		} auth_only;
> > +		struct {
> > +			uint32_t aead_ofs;
> > +			uint32_t aead_len;
> > +			rte_iova_t tag_iova;
> > +			uint8_t *aad;
> > +			rte_iova_t aad_iova;
> > +		} aead;
> > +		struct {
> > +			uint32_t cipher_ofs;
> > +			uint32_t cipher_len;
> > +			uint32_t auth_ofs;
> > +			uint32_t auth_len;
> > +			rte_iova_t digest_iova;
> > +		} chain;
> > +	};
> > +	uint8_t *iv;
> > +	rte_iova_t iv_iova;
> > +};
>=20
> NACK,
> Why do you need this structure definitions again when you have similar on=
es
> (the ones used in CPU crypto) available for the same purpose.
> In case of CPU crypto, there were 2 main requirements
> - synchronous API instead of enq +deq
> - raw buffers.
>=20

As you may have seen the structure definition is hW centric with the
IOVA addresses all over. Also as you will from the patch series the operati=
on is=20
Per operation basis instead of operating in a burst. The external applicati=
on
may sooner know when a specific enqueue is failed.=20

> Now for this patchset, the requirement is
> - raw buffers
> - asynchronous APIs
>=20
> The data structure for raw buffers and crypto related offsets are already
> defined
> So they should be reused.
> And I believe with some changes in rte_crypto_op  and rte_crypto_sym_op,
> We can support raw buffers with the same APIs.
> Instead of m_src and m_dst, raw buffer data structures can be combined in=
 a
> Union and some of the fields in the rte_crypto_op can be left NULL in cas=
e of
> raw buffers.
>=20

This is a good point but we still face too many unnecessary fields to be NU=
LL, such as
digest pointers, I have given a lot thought to this structure. Hopefully it=
 covers
all vendor's HW symmetric crypto needs and in the same time it well squeeze=
=20
the required HW addresses into 1 cacheline, instead of rte_crypto_op +=20
rte_crypto_sym_op 3 cacheline footprint. Another purpose of the structure d=
esign
is the structure buffer can be taken from stack and can be used to fill all
jobs to the PMD HW.

>=20
> > +/* Struct for user to perform HW specific enqueue/dequeue function cal=
ls
> */
> > +struct rte_crypto_hw_ops {
> > +	/* Driver written queue pair data pointer, should NOT be alterred by
> > +	 * the user.
> > +	 */
> > +	void *qp;
> > +	/* Function handler to enqueue AEAD job */
> > +	rte_crypto_hw_enq_cb_fn enqueue_aead;
> > +	/* Function handler to enqueue cipher only job */
> > +	rte_crypto_hw_enq_cb_fn enqueue_cipher;
> > +	/* Function handler to enqueue auth only job */
> > +	rte_crypto_hw_enq_cb_fn enqueue_auth;
> > +	/* Function handler to enqueue cipher + hash chaining job */
> > +	rte_crypto_hw_enq_cb_fn enqueue_chain;
> > +	/* Function handler to query processed jobs */
> > +	rte_crypto_hw_query_processed query_processed;
> > +	/* Function handler to dequeue one job and return opaque data
> stored
> > */
> > +	rte_crypto_hw_deq_one_cb_fn dequeue_one;
> > +	/* Function handler to dequeue many jobs */
> > +	rte_crypto_hw_deq_many_cb_fn dequeue_many;
> > +	/* Reserved */
> > +	void *reserved[8];
> > +};
>=20
> Why do we need such callbacks in the library?
> These should be inside the drivers, or else we do the same for
> Legacy case as well. The pain of finding the correct enq function for
> Appropriate crypto operation is already handled by all the drivers
> And we can reuse that or else we modify it there as well.
>=20

Providing different types of enqueue functions for specific operation type
could save a lot of branches for the driver to handle. As mentioned this
data-path API is intended to be used as an advanced feature to provide
close-to-native perf to external library/applications that are not mbuf
centric. And I don't agree classifying choosing 1 enqueue function from
4 candidates as "pain".

> We should not add a lot of data paths for the user, otherwise the
> APIs will become centric to a particular vendor and it will be very diffi=
cult
> For the user to migrate from one vendor to another and would defeat the
> Purpose of DPDK which provide uniform abstraction layer for all the
> hardware
> Vendors.
>=20

The purpose of adding data-path for the user is performance for non-mbuf
data-path centric applications/libraries, in the meantime not creating
confusion. In this version we aim to provide a more friendly data-path for
them, and aims to be useful to all vendor's PMDs. If there is any place in
the API that blocks a PMD please let me know.

> Adding other vendors to comment.
>=20
> Regards,
> Akhil