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 6921AA0613 for ; Fri, 27 Sep 2019 11:26:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 806C02C30; Fri, 27 Sep 2019 11:26:45 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130047.outbound.protection.outlook.com [40.107.13.47]) by dpdk.org (Postfix) with ESMTP id 730EE2C2F for ; Fri, 27 Sep 2019 11:26:44 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c7pGZbVvYEkc9+woP7/KNXViUGjL9iaTTEVmUeqBuZVz+d8R4z8jRTZVJqHzVxHdr6RldWGwhFER1YEy0NW1wAVcYjBmDiMqaPigUBuTufTr+gVQ+dmvpAeW50u+kMwklJ+ra+XAdsiXVBwJ9Pr2+yLHXw5EOXV3NQpgz4k7wC3/6GNmN3re30wNmLhyP7bC7mEng07nQmrEw9pEWoeK+gX2TZi2c7fjlE4+QL9+OjTKdpkFy/NNTrsMcrMrzQhZIR+3n0n5Qg+ENZxhv9r1agmau/nZjUce4Gtpoh2TRQMFaGBDCcIeR7UP+y320w3pBDu8Ax/g9WdqhWxdmbRb+Q== 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=ikjxIpwqM7t4gtRgSE69EJkxelPwEYOm0rJEPnyQfk4=; b=gLuMbtaDVcb36lnjjq2GFoZ8xtPo2h5abiF4L00Sp7DJoBk/irlKFK94LMBiQQp3Re+q++EBiwhaXFjTJj33rUENSKYm8lZFV4TVcjHBXZELOELaDXUPcqQOcLVH868OVVS0m9ZT8zn4Lo31WT1Z/H2M2aod4zWpeEVfRb+xUvW3/lSbiECGlK0YeHnAe3DNvbi6QnKj4rvv86MA4ejS15apR6X06YnpSJDaspeNXV/A/z7vJOQ7mcDFQZS+Fk89AIXgfjoDTEA8lmvVEAsOiYZR0V3vjwGk16KFArdVM0DM0QsYm4XoivsP6RB7RTVADVntP4gxA+fhpI2cL4rPhA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ikjxIpwqM7t4gtRgSE69EJkxelPwEYOm0rJEPnyQfk4=; b=O2k2Pg5mbwRz7sywGRLFpKEFMInWiqtlxA56L2aARmMy9Hr+HN0dgO+29Isd0W9TiM7heZfxkjYUiezV8vuNTC6IeTIZTkMMBkzMRLsKN45x0VKQfzLzeqlJBqZXh4QxlNOTniAWl+56uLM7wkS1uqOnX7h5LTfIYizxeTfDD3I= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (10.255.118.11) by VE1PR04MB6493.eurprd04.prod.outlook.com (20.179.233.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.17; Fri, 27 Sep 2019 09:26:42 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::c045:5df2:ba1f:c3ee]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::c045:5df2:ba1f:c3ee%5]) with mapi id 15.20.2305.017; Fri, 27 Sep 2019 09:26:42 +0000 From: Akhil Goyal To: "Ananyev, Konstantin" , "'dev@dpdk.org'" , "De Lara Guarch, Pablo" , 'Thomas Monjalon' CC: "Zhang, Roy Fan" , "Doherty, Declan" , 'Anoob Joseph' Thread-Topic: [RFC PATCH 1/9] security: introduce CPU Crypto action type and API Thread-Index: AQHVYm4LqyJkewM9NkuUWAfAmrqx1acbUiZggAAsN4CAAtsIgIAAT02AgAYXC5CAAbSDgIABbRGggAaWxgCAAPjG4IABs/OAgAuzNYCAAoY34A== Date: Fri, 27 Sep 2019 09:26:42 +0000 Message-ID: References: <20190903154046.55992-1-roy.fan.zhang@intel.com> <20190903154046.55992-2-roy.fan.zhang@intel.com> <9F7182E3F746AB4EA17801C148F3C6043369D686@IRSMSX101.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580191926A17@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580191962CD5@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580191966116@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580191966C23@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258019196A767@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258019196A767@irsmsx105.ger.corp.intel.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [92.120.1.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5600c1e7-3480-48f5-f1c9-08d7432ccef8 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: VE1PR04MB6493: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0173C6D4D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(39860400002)(396003)(366004)(346002)(52314003)(51444003)(199004)(189003)(13464003)(53546011)(8676002)(4326008)(6506007)(76176011)(14454004)(66556008)(64756008)(66446008)(229853002)(66476007)(33656002)(6246003)(256004)(316002)(74316002)(476003)(14444005)(15650500001)(86362001)(30864003)(110136005)(561944003)(81156014)(76116006)(2906002)(81166006)(66946007)(6436002)(486006)(9686003)(55016002)(186003)(5660300002)(54906003)(11346002)(7696005)(446003)(44832011)(52536014)(25786009)(66066001)(6116002)(478600001)(3846002)(8936002)(7736002)(305945005)(71190400001)(71200400001)(102836004)(99286004)(26005)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6493; H:VE1PR04MB6639.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bsNclvFVd3TFCr4rAOWpcBWgt2ri6b7GTEyzO6Ud7AzQmQ/YyxiBgrWH8rnXklKaK11jwZKZMK/qPnliUbCZfgnjKow+/rtaPZ7cf3BcKG4I7Xb9QfjPv4oPE1SsMybFBvJNJHKLfQmw+44ZeUxCsdhDdr5ukNrW+e33+4iYJ3gjqEQYU4kAUOax5ttRUAawvAe9x4hFgvLYaZ9XW1cI06/LrkELfUQ2n50IYX9op7VZj5sh63g3yKYXu6k2oeWwLd+/4Gog/SdYcJN8zNbtMy/Mq4blNDGkLScOqbFO2TDIWSDCgmhVrxCqM8XBGXWcpEdk3dCnaGXn5uJx43NZ/1PARBKXuX3xjYD0L4lHHSDHpoDCMzpyyh99jOv1Y+FlCSlqMC6rMFpg2t8AjRR9txlZBvY+J7SnigDioidmRC0= x-ms-exchange-transport-forked: True 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: 5600c1e7-3480-48f5-f1c9-08d7432ccef8 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2019 09:26:42.4279 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: x4/K7YRYAfDrZJnwXOtsYctFAD9kvt0/PQ1HVYTwU2F/IjN+qyeWv8rtZfZ5RQcmtT8gSHrUNoXVkDQmhlRzsA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6493 Subject: Re: [dpdk-dev] [RFC PATCH 1/9] security: introduce CPU Crypto action type and 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Konstantin, > -----Original Message----- > From: Ananyev, Konstantin > Sent: Wednesday, September 25, 2019 11:54 PM > To: Akhil Goyal ; 'dev@dpdk.org' ; De > Lara Guarch, Pablo ; 'Thomas Monjalon' > > Cc: Zhang, Roy Fan ; Doherty, Declan > ; 'Anoob Joseph' > Subject: RE: [RFC PATCH 1/9] security: introduce CPU Crypto action type a= nd API >=20 >=20 > > > > > > > > > > This action type allows the burst of symmetric crypto w= orkload > using > > > > the > > > > > > > > same > > > > > > > > > > algorithm, key, and direction being processed by CPU cy= cles > > > > > > synchronously. > > > > > > > > > > This flexible action type does not require external har= dware > > > > involvement, > > > > > > > > > > having the crypto workload processed synchronously, and= is > more > > > > > > > > performant > > > > > > > > > > than Cryptodev SW PMD due to the saved cycles on remove= d > "async > > > > > > mode > > > > > > > > > > simulation" as well as 3 cacheline access of the crypto= ops. > > > > > > > > > > > > > > > > > > Does that mean application will not call the > cryptodev_enqueue_burst > > > > and > > > > > > > > corresponding dequeue burst. > > > > > > > > > > > > > > > > Yes, instead it just call rte_security_process_cpu_crypto_b= ulk(...) > > > > > > > > > > > > > > > > > It would be a new API something like process_packets and = it will > have > > > > the > > > > > > > > crypto processed packets while returning from the API? > > > > > > > > > > > > > > > > Yes, though the plan is that API will operate on raw data b= uffers, > not > > > > mbufs. > > > > > > > > > > > > > > > > > > > > > > > > > > I still do not understand why we cannot do with the conve= ntional > > > > crypto lib > > > > > > > > only. > > > > > > > > > As far as I can understand, you are not doing any protoco= l > processing > > > > or > > > > > > any > > > > > > > > value add > > > > > > > > > To the crypto processing. IMO, you just need a synchronou= s > crypto > > > > > > processing > > > > > > > > API which > > > > > > > > > Can be defined in cryptodev, you don't need to re-create = a crypto > > > > session > > > > > > in > > > > > > > > the name of > > > > > > > > > Security session in the driver just to do a synchronous p= rocessing. > > > > > > > > > > > > > > > > I suppose your question is why not to have > > > > > > > > rte_crypot_process_cpu_crypto_bulk(...) instead? > > > > > > > > The main reason is that would require disruptive changes in= existing > > > > > > cryptodev > > > > > > > > API > > > > > > > > (would cause ABI/API breakage). > > > > > > > > Session for RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO need > some > > > > extra > > > > > > > > information > > > > > > > > that normal crypto_sym_xform doesn't contain > > > > > > > > (cipher offset from the start of the buffer, might be somet= hing extra > in > > > > > > future). > > > > > > > > > > > > > > Cipher offset will be part of rte_crypto_op. > > > > > > > > > > > > fill/read (+ alloc/free) is one of the main things that slowdow= n current > > > > crypto-op > > > > > > approach. > > > > > > That's why the general idea - have all data that wouldn't chang= e from > packet > > > > to > > > > > > packet > > > > > > included into the session and setup it once at session_init(). > > > > > > > > > > I agree that you cannot use crypto-op. > > > > > You can have the new API in crypto. > > > > > As per the current patch, you only need cipher_offset which you c= an have > it as > > > > a parameter until > > > > > You get it approved in the crypto xform. I believe it will be ben= eficial in > case of > > > > other crypto cases as well. > > > > > We can have cipher offset at both places(crypto-op and cipher_xfo= rm). It > will > > > > give flexibility to the user to > > > > > override it. > > > > > > > > After having another thought on your proposal: > > > > Probably we can introduce new rte_crypto_sym_xform_types for CPU > related > > > > stuff here? > > > > > > I also thought of adding new xforms, but that wont serve the purpose = for > may be all the cases. > > > You would be needing all information currently available in the curre= nt > xforms. > > > So if you are adding new fields in the new xform, the size will be mo= re than > that of the union of xforms. > > > ABI breakage would still be there. > > > > > > If you think a valid compression of the AEAD xform can be done, then = that > can be done for each of the > > > Xforms and we can have a solution to this issue. > > > > I think that we can re-use iv.offset for our purposes (for crypto offse= t). > > So for now we can make that path work without any ABI breakage. > > Fan, please feel free to correct me here, if I missed something. > > If in future we would need to add some extra information it might > > require ABI breakage, though by now I don't envision anything particula= r to > add. > > Anyway, if there is no objection to go that way, we can try to make > > these changes for v2. > > >=20 > Actually, after looking at it more deeply it appears not that easy as I t= hought it > would be :) > Below is a very draft version of proposed API additions. > I think it avoids ABI breakages right now and provides enough flexibility= for > future extensions (if any). > For now, it doesn't address your comments about naming conventions (_CPU_ > vs _SYNC_) , etc. > but I suppose is comprehensive enough to provide a main idea beyond it. > Akhil and other interested parties, please try to review and provide feed= back > ASAP, > as related changes would take some time and we still like to hit 19.11 de= adline. > Konstantin >=20 > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h > b/lib/librte_cryptodev/rte_crypto_sym.h > index bc8da2466..c03069e23 100644 > --- a/lib/librte_cryptodev/rte_crypto_sym.h > +++ b/lib/librte_cryptodev/rte_crypto_sym.h > @@ -103,6 +103,9 @@ rte_crypto_cipher_operation_strings[]; > * > * This structure contains data relating to Cipher (Encryption and Decry= ption) > * use to create a session. > + * Actually I was wrong saying that we don't have free space inside xfor= ms. > + * Making key struct packed (see below) allow us to regain 6B that could= be > + * used for future extensions. > */ > struct rte_crypto_cipher_xform { > enum rte_crypto_cipher_operation op; > @@ -116,7 +119,25 @@ struct rte_crypto_cipher_xform { > struct { > const uint8_t *data; /**< pointer to key data */ > uint16_t length; /**< key length in bytes */ > - } key; > + } __attribute__((__packed__)) key; > + > + /** > + * offset for cipher to start within user provided data buffer. > + * Fan suggested another (and less space consuming way) - > + * reuse iv.offset space below, by changing: > + * struct {uint16_t offset, length;} iv; > + * to uunamed union: > + * union { > + * struct {uint16_t offset, length;} iv; > + * struct {uint16_t iv_len, crypto_offset} cpu_crypto_param; > + * }; > + * Both approaches seems ok to me in general. No strong opinions here. OK with this one. > + * Comments/suggestions are welcome. > + */ > + uint16_t offset; > + > + uint8_t reserved1[4]; > + > /**< Cipher key > * > * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data w= ill > @@ -284,7 +305,7 @@ struct rte_crypto_auth_xform { > struct { > const uint8_t *data; /**< pointer to key data */ > uint16_t length; /**< key length in bytes */ > - } key; > + } __attribute__((__packed__)) key; > /**< Authentication key data. > * The authentication key length MUST be less than or equal to th= e > * block size of the algorithm. It is the callers responsibility = to > @@ -292,6 +313,8 @@ struct rte_crypto_auth_xform { > * (for example RFC 2104, FIPS 198a). > */ >=20 > + uint8_t reserved1[6]; > + > struct { > uint16_t offset; > /**< Starting point for Initialisation Vector or Counter, > @@ -376,7 +399,12 @@ struct rte_crypto_aead_xform { > struct { > const uint8_t *data; /**< pointer to key data */ > uint16_t length; /**< key length in bytes */ > - } key; > + } __attribute__((__packed__)) key; > + > + /** offset for cipher to start within data buffer */ > + uint16_t cipher_offset; > + > + uint8_t reserved1[4]; >=20 > struct { > uint16_t offset; > diff --git a/lib/librte_cryptodev/rte_cryptodev.h > b/lib/librte_cryptodev/rte_cryptodev.h > index e175b838c..c0c7bfed7 100644 > --- a/lib/librte_cryptodev/rte_cryptodev.h > +++ b/lib/librte_cryptodev/rte_cryptodev.h > @@ -1272,6 +1272,101 @@ void * > rte_cryptodev_sym_session_get_user_data( > struct rte_cryptodev_sym_session = *sess); >=20 > +/* > + * After several thoughts decided not to try to squeeze CPU_CRYPTO > + * into existing rte_crypto_sym_session structure/API, but instead > + * introduce an extentsion to it via new fully opaque > + * struct rte_crypto_cpu_sym_session and additional related API. What all things do we need to squeeze? In this proposal I do not see the new struct cpu_sym_session defined here. I believe you will have same lib API/struct for cpu_sym_session and sym_se= ssion. I am not sure if that would be needed. It would be internal to the driver that if synchronous processing is suppor= ted(from feature flag) and Have relevant fields in xform(the newly added ones which are packed as per = your suggestions) set, It will create that type of session. > + * Main points: > + * - Current crypto-dev API is reasonably mature and it is desirable > + * to keep it unchanged (API/ABI stability). From other side, this > + * new sync API is new one and probably would require extra changes. > + * Having it as a new one allows to mark it as experimental, without > + * affecting existing one. > + * - Fully opaque cpu_sym_session structure gives more flexibility > + * to the PMD writers and again allows to avoid ABI breakages in futur= e. > + * - process() function per set of xforms > + * allows to expose different process() functions for different > + * xform combinations. PMD writer can decide, does he wants to > + * push all supported algorithms into one process() function, > + * or spread it across several ones. > + * I.E. More flexibility for PMD writer. Which process function should be chosen is internal to PMD, how would that = info be visible to the application or the library. These will get stored in the = session private data. It would be upto the PMD writer, to store the per session process fun= ction in the session private data. Process function would be a dev ops just like enc/deq operations and it sho= uld call The respective process API stored in the session private data. I am not sure if you would need a new session init API for this as nothing = would be visible to the app or lib. > + * - Not storing process() pointer inside the session - > + * Allows user to choose does he want to store a process() pointer > + * per session, or per group of sessions for that device that share > + * the same input xforms. I.E. extra flexibility for the user, > + * plus allows us to keep cpu_sym_session totally opaque, see above. If multiple sessions need to be processed via the same process function,=20 PMD would save the same process in all the sessions, I don't think there wo= uld be any perf overhead with that. > + * Sketched usage model: > + * .... > + * /* control path, alloc/init session */ > + * int32_t sz =3D rte_crypto_cpu_sym_session_size(dev_id, &xform); > + * struct rte_crypto_cpu_sym_session *ses =3D user_alloc(..., sz); > + * rte_crypto_cpu_sym_process_t process =3D > + * rte_crypto_cpu_sym_session_func(dev_id, &xform); > + * rte_crypto_cpu_sym_session_init(dev_id, ses, &xform); > + * ... > + * /* data-path*/ > + * process(ses, ....); > + * .... > + * /* control path, termiante/free session */ > + * rte_crypto_cpu_sym_session_fini(dev_id, ses); > + */ > + > +/** > + * vector structure, contains pointer to vector array and the length > + * of the array > + */ > +struct rte_crypto_vec { > + struct iovec *vec; > + uint32_t num; > +}; > + > +/* > + * Data-path bulk process crypto function. > + */ > +typedef void (*rte_crypto_cpu_sym_process_t)( > + struct rte_crypto_cpu_sym_session *sess, > + struct rte_crypto_vec buf[], void *iv[], void *aad[], > + void *digest[], int status[], uint32_t num); > +/* > + * for given device return process function specific to input xforms > + * on error - return NULL and set rte_errno value. > + * Note that for same input xfroms for the same device should return > + * the same process function. > + */ > +__rte_experimental > +rte_crypto_cpu_sym_process_t > +rte_crypto_cpu_sym_session_func(uint8_t dev_id, > + const struct rte_crypto_sym_xform *xforms); > + > +/* > + * Return required session size in bytes for given set of xforms. > + * if xforms =3D=3D NULL, then return the max possible session size, > + * that would fit session for any supported by the device algorithm. > + * if CPU mode is not supported at all, or requeted in xform > + * algorithm is not supported, then return -ENOTSUP. > + */ > +__rte_experimental > +int > +rte_crypto_cpu_sym_session_size(uint8_t dev_id, > + const struct rte_crypto_sym_xform *xforms); > + > +/* > + * Initialize session. > + * It is caller responsibility to allocate enough space for it. > + * See rte_crypto_cpu_sym_session_size above. > + */ > +__rte_experimental > +int rte_crypto_cpu_sym_session_init(uint8_t dev_id, > + struct rte_crypto_cpu_sym_session *sess, > + const struct rte_crypto_sym_xform *xforms); > + > +__rte_experimental > +void > +rte_crypto_cpu_sym_session_fini(uint8_t dev_id, > + struct rte_crypto_cpu_sym_session *sess); > + > + > #ifdef __cplusplus > } > #endif > diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h > b/lib/librte_cryptodev/rte_cryptodev_pmd.h > index defe05ea0..ed7e63fab 100644 > --- a/lib/librte_cryptodev/rte_cryptodev_pmd.h > +++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h > @@ -310,6 +310,20 @@ typedef void (*cryptodev_sym_free_session_t)(struct > rte_cryptodev *dev, > typedef void (*cryptodev_asym_free_session_t)(struct rte_cryptodev *dev, > struct rte_cryptodev_asym_session *sess); >=20 > +typedef int (*cryptodev_cpu_sym_session_size_t) (struct rte_cryptodev *d= ev, > + const struct rte_crypto_sym_xform *xforms); > + > +typedef int (*cryptodev_cpu_sym_session_init_t) (struct rte_cryptodev *d= ev, > + struct rte_crypto_cpu_sym_session *sess, > + const struct rte_crypto_sym_xform *xforms); > + > +typedef void (*cryptodev_cpu_sym_session_fini_t) (struct rte_cryptodev *= dev, > + struct rte_crypto_cpu_sym_session *sess); > + > +typedef rte_crypto_cpu_sym_process_t (*cryptodev_cpu_sym_session_func_t) > ( > + struct rte_cryptodev *dev, > + const struct rte_crypto_sym_xform *xforms); > + > /** Crypto device operations function pointer table */ > struct rte_cryptodev_ops { > cryptodev_configure_t dev_configure; /**< Configure device. */ > @@ -343,6 +357,11 @@ struct rte_cryptodev_ops { > /**< Clear a Crypto sessions private data. */ > cryptodev_asym_free_session_t asym_session_clear; > /**< Clear a Crypto sessions private data. */ > + > + cryptodev_cpu_sym_session_size_t sym_cpu_session_get_size; > + cryptodev_cpu_sym_session_func_t sym_cpu_session_get_func; > + cryptodev_cpu_sym_session_init_t sym_cpu_session_init; > + cryptodev_cpu_sym_session_fini_t sym_cpu_session_fini; > }; >=20 >=20 >=20