From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id BE0EAA0C4B; Thu, 21 Oct 2021 12:38:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 476854116A; Thu, 21 Oct 2021 12:38:46 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id E6D5A410E2 for ; Thu, 21 Oct 2021 12:38:44 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10143"; a="252498464" X-IronPort-AV: E=Sophos;i="5.87,169,1631602800"; d="scan'208";a="252498464" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Oct 2021 03:38:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,169,1631602800"; d="scan'208";a="595050852" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by orsmga004.jf.intel.com with ESMTP; 21 Oct 2021 03:38:36 -0700 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Thu, 21 Oct 2021 03:38:35 -0700 Received: from fmsmsx607.amr.corp.intel.com (10.18.126.87) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Thu, 21 Oct 2021 03:38:35 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx607.amr.corp.intel.com (10.18.126.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Thu, 21 Oct 2021 03:38:35 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.170) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Thu, 21 Oct 2021 03:38:34 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OEd89bXgd/xTB6UII5KKWnYWsMt2W2TtYado5aFIXdiehi1tnfk3BLAACMO04zaOcJqxsexKca7BP6PahQqLQhQi22G5WP6WLLu+QMvdlxtg2kQRWCPNsTrs7mKgD5ZPM4hw8NwDO7mCNMGQ32C19hAqikRaWbU3AQHrkAvjXiv+4yJrjtdbO1uuYMkX5Q17s26qmVTheHBCpxTKej9ZcS60RyRjbPgpI1YPTRUBiyo5qpdvuGk3g/OpgK+fQFb55p+FUpi4lPiDdU2jvUfCKBU7oMRt4/ChJjOQovW5ZyoZXwq8ej61LhHGb9z5gxEcxOka8agj/zN+VL6avVOCyw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iEy5bjc2UWM2SeTWMPR3C1Nafz/+/xQ667ZCu/BHm/4=; b=gmiz/zSbhD1ysBqC8481gxCMd174rqHPu+OC+m17PSF7LGgliFjwWqTH5/nDVOSXcbZfL5amS4Yc3LX8his/svFvwZpJdRl5Otu+0UhIKHrFchVvraejwB1xf6Yb7f0Hal1i2pEoJwzexlPCMgtcqMu72HlgNWfInkh2sTcFL6RefN2oh6D3M8HB2ceGaxMumcma2xO65oy8Fp4XOOsiPSwHj7UfFE6ZrHwqS8GG3zLSrbUBCzRuoA3lEFCiesnraUVUtDntByhV48V1rF7AX/ptjF+aRrVS7CFn7ER8LDTf31tZM8qjWs1daDzaL5O8mfBjd1K/Gc5jJGbjbKMjCw== 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=iEy5bjc2UWM2SeTWMPR3C1Nafz/+/xQ667ZCu/BHm/4=; b=Mo2HJHKWDl07SUqecifYOmCsbBQ1DgDNFnoJLDZkUs7mGArs4BdbKWD1SS8TyjUgAfvapTVfZ7FaJ7lCiN8vyhayeBH2eVA8birsd2QRcVLRCKckl0WqZs+Xip4ZWY/zyUQcM7daygyBddKjlYz/Z1m//X20d9cCvKWzt47HJEU= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM6PR11MB3577.namprd11.prod.outlook.com (2603:10b6:5:137::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.18; Thu, 21 Oct 2021 10:38:33 +0000 Received: from DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::2c0c:5383:f814:3b4e]) by DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::2c0c:5383:f814:3b4e%6]) with mapi id 15.20.4628.018; Thu, 21 Oct 2021 10:38:33 +0000 From: "Ananyev, Konstantin" To: Akhil Goyal , "dev@dpdk.org" CC: "thomas@monjalon.net" , "david.marchand@redhat.com" , "hemant.agrawal@nxp.com" , Anoob Joseph , "De Lara Guarch, Pablo" , "Trahe, Fiona" , "Doherty, Declan" , "matan@nvidia.com" , "g.singh@nxp.com" , "Zhang, Roy Fan" , "jianjay.zhou@huawei.com" , "asomalap@amd.com" , "ruifeng.wang@arm.com" , "Nicolau, Radu" , "ajit.khaparde@broadcom.com" , Nagadheeraj Rottela , Ankur Dwivedi , "Power, Ciara" , "Wang, Haiyue" , "jiawenwu@trustnetic.com" , "jianwang@trustnetic.com" Thread-Topic: [PATCH v3 6/8] cryptodev: rework session framework Thread-Index: AQHXxGgs8uA5efxFxkuDtx/p8VXwcKvcQbSwgADGSQCAADYUkA== Date: Thu, 21 Oct 2021 10:38:33 +0000 Message-ID: References: <20211013192222.1582631-2-gakhil@marvell.com> <20211018213452.2734720-1-gakhil@marvell.com> <20211018213452.2734720-7-gakhil@marvell.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.200.16 authentication-results: marvell.com; dkim=none (message not signed) header.d=none;marvell.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d3f1c1b7-befa-4409-54f8-08d9947eee3c x-ms-traffictypediagnostic: DM6PR11MB3577: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZNYWXGtN57GcZQJvQkyjx6MRmfm/JMV+I4vQzzuyc//Ryq+pk+xCqbXaQVHijeVkirD5aNB0iNB4gdvCvQcff5y/2bHRIzi3gQr+hO7Q/d0xE8E4Kh+WOyp6sVxim0vOB4WnWM0erH/C3gpCImaDahSjLChyfQSiE2SyVuTdeNgSeVJoNmVmaXlJmfISFvHGc8dm7FK7NFefKjMGga2qhJ6HY7q6EH5Zwp24PsxXS4KvIAkKgwejsiZpIYxVLh8HxyyL7y7SDSYrRTjQrJW6d6lte8mDVPCqNTBGGdxTfDPECdxqyGkR8j6BoMAHo/y1He6G5GRzjv4V8b6Nfomp1PvCxWy3A0OgJWCSLf6m9gByKRlx98RKDDnKnGEo3+CGS+xNlczTyDRlvYHFzSb9Jb46xN7DgLu+UO+4mCmywmRoW9NIBDEjGMKMIPAeb4n6w1GeD7KTaRf3sKMFRiAghfwrAYLw67cpXOdzW/SuazT+TNF09LgZ7TnQAkSYqJ0+usNilnIwwc5ZnvZysS2/NcRneJCAep8JE1e37SJCGZ47GkLFGEp5PuKR2gnhX9MpSpxN+z1xd3jbGJYw67TQUa0asiE0GmPjDBnFLrbSNbOlXfebg/ggLJ1w9PD/MTdUSCvoiPeDR5eijfao4KI4DhNc549WfqCJa11WirXvXWD1Hrn51gTiyPcbPNgJwMtgzmxL5oSe1gK5U8XkbouaRw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4491.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(64756008)(5660300002)(52536014)(71200400001)(8676002)(66446008)(66946007)(66476007)(38100700002)(2906002)(86362001)(19627235002)(66556008)(122000001)(33656002)(76116006)(186003)(82960400001)(7696005)(83380400001)(6506007)(316002)(55016002)(8936002)(54906003)(55236004)(7416002)(26005)(110136005)(9686003)(508600001)(4326008)(38070700005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?us53kox0c+g1xsv+xa7ehFWseIeV7d+UEalSTSOwK4VYMY1wMn6yIQmgLiVF?= =?us-ascii?Q?3VSZ/9eJ3E/2YPtvDX50X7PHto93+GR514+mjhUpupjHxB9r0x9iE63LPk+5?= =?us-ascii?Q?bC8Hcm9qhKLHul1kkqSKCUtMdfkcLKFHZbT4Exuizyub5aBgglM2NqKrjBIA?= =?us-ascii?Q?OacVT3pRZ86xVKE8bdjRP36Zk5+hoA2y7Z2Y/pjbVZPQiv/rMiB7bPk+OA4G?= =?us-ascii?Q?59z896jETocd6nPKhQlsbfjy3SujFAHD7wubUPH4bTQvCB/rayFiyEDUEUUU?= =?us-ascii?Q?nuL95Q3C0c8m5AzadXOujqiFMk2mbTzogMmHB/qmwTVK9MR5xY360NCjewDI?= =?us-ascii?Q?qbATRkPFaYGGJTTSorDectv3vevZzr+lcnfK0T7reyNfGqoivsYvT5ls8AQK?= =?us-ascii?Q?TWjF55lM9STXPlgcViRLKgGhe69O5l2MraViGCsyeYS2Z/la27FdGWFVzzTP?= =?us-ascii?Q?iOBQOMAcNUMBEZwcwdAZqdHcw4LL3w0PguII6xzhCmXIEzxjIIh4ZiLZmDDw?= =?us-ascii?Q?Iuvpt7U7ZPicILYdZUAB9y4cnBldAui2hvhmYHooEharQqSFxQ7G938rQ8ZD?= =?us-ascii?Q?Y/HKnElePcBwMOAhYggq/9ENK7rzLN9lMCZmbbDfE6/7w0nUFaqydzzF1+dO?= =?us-ascii?Q?84nMTCGScNzrkasFTmZfjbiBQA99hd74nTCXsAWpk2Sfh5Zkvhu7CgBZLrJW?= =?us-ascii?Q?PPtuMN7026oTp1P/onB6pJCx56uP8/xd+4jdW2EayGEwhLP03gCxpytIMKZC?= =?us-ascii?Q?JXWh4lZ+NnIbr/W2nM35qVf9J4rugM8ndO/eQqpNnTO/Fzf7jIv98Ix+8oIv?= =?us-ascii?Q?zHnDJznSkbD9Lmgpd8kRm9r/QsW27SsxG0KTetoyi89XzedEZ4jBc3CXBRPX?= =?us-ascii?Q?0gcsgRAZW0+zCLDPsynIQJ2HR1uGE9yW0dpceAXotCqmc2T62DvlwgeLl9bb?= =?us-ascii?Q?hQBKz5bS9nsx91cH4zv26nfXmjRuZOheRvxEIz47X5UvLNPorg7ZsDezgORT?= =?us-ascii?Q?V5nLAcjjrwjCaDLEsKjtDccDzFHMNbP0NTJZoEPlvbqJ+vInhBUnzARM8IwE?= =?us-ascii?Q?bVQF1uEjWJmn9ESyxh5axgPYpAn1rDT53KmLpYzMxLVDpa23uwjOqSJakVlw?= =?us-ascii?Q?YBhPK1GUIiLkBPqj8Eb3wM3VgYVr18Yi2M69b7w1szxvTe6DMQjVfBmHsxoh?= =?us-ascii?Q?vFKJF8XykkqVWe4u6IE3k5wGDipnTPWT9Mr6W5r7nRigHlWN4yjqQizxJxJt?= =?us-ascii?Q?dK0kyBFFjW5hkOVA4/HpDgjIeoJy1AdB2m9dxChyPRx1MmaaaWC8Cq+GMtIC?= =?us-ascii?Q?4UbAq7sOorxLbykkKqkTtPhw?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB4491.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d3f1c1b7-befa-4409-54f8-08d9947eee3c X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2021 10:38:33.1768 (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: konstantin.ananyev@intel.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3577 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v3 6/8] cryptodev: rework session framework X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" > > > As per current design, rte_cryptodev_sym_session_create() and > > > rte_cryptodev_sym_session_init() use separate mempool objects > > > for a single session. > > > And structure rte_cryptodev_sym_session is not directly used > > > by the application, it may cause ABI breakage if the structure > > > is modified in future. > > > > > > To address these two issues, the rte_cryptodev_sym_session_create > > > will take one mempool object for both the session and session > > > private data. The API rte_cryptodev_sym_session_init will now not > > > take mempool object. > > > rte_cryptodev_sym_session_create will now return an opaque session > > > pointer which will be used by the app in rte_cryptodev_sym_session_in= it > > > and other APIs. > > > > > > With this change, rte_cryptodev_sym_session_init will send > > > pointer to session private data of corresponding driver to the PMD > > > based on the driver_id for filling the PMD data. > > > > > > In data path, opaque session pointer is attached to rte_crypto_op > > > and the PMD can call an internal library API to get the session > > > private data pointer based on the driver id. > > > > > > Note: currently nb_drivers are getting updated in RTE_INIT which > > > result in increasing the memory requirements for session. > > > User can compile off drivers which are not in use to reduce the > > > memory consumption of a session. > > > > > > Signed-off-by: Akhil Goyal > > > --- > > > > With that patch ipsec-secgw functional tests crashes for AES_GCM test-c= ases. > > To be more specific: > > examples/ipsec-secgw/test/run_test.sh -4 tun_aesgcm > > > > [24126592.561071] traps: dpdk-ipsec-secg[3254860] general protection fa= ult > > ip:7f3ac2397027 sp:7ffeaade8848 error:0 in > > libIPSec_MB.so.1.0.0[7f3ac238f000+2a20000] > > > > Looking a bit deeper, it fails at: > > #0 0x00007ff9274f4027 in aes_keyexp_128_enc_avx512 () > > from /lib/libIPSec_MB.so.1 > > #1 0x00007ff929f0ac97 in aes_gcm_pre_128_avx_gen4 () > > from /lib/libIPSec_MB.so.1 > > #2 0x0000561757073753 in aesni_gcm_session_configure > > (mb_mgr=3D0x56175c5fe400, > > session=3D0x17e3b72d8, xform=3D0x17e05d7c0) > > at ../drivers/crypto/ipsec_mb/pmd_aesni_gcm.c:132 > > #3 0x00005617570592af in ipsec_mb_sym_session_configure ( > > dev=3D0x56175be0c940 , xform=3D0x17e05d7c0, > > sess=3D0x17e3b72d8) at ../drivers/crypto/ipsec_mb/ipsec_mb_ops.c:33= 0 > > #4 0x0000561753b4d6ae in rte_cryptodev_sym_session_init (dev_id=3D0 > > '\000', > > sess_opaque=3D0x17e3b4940, xforms=3D0x17e05d7c0) > > at ../lib/cryptodev/rte_cryptodev.c:1736 > > #5 0x0000561752ef99b7 in create_lookaside_session ( > > ipsec_ctx=3D0x56175aa6a210 , sa=3D0x17e05d140, > > ips=3D0x17e05d140) at ../examples/ipsec-secgw/ipsec.c:145 > > #6 0x0000561752f0cf98 in fill_ipsec_session (ss=3D0x17e05d140, > > ctx=3D0x56175aa6a210 , sa=3D0x17e05d140) > > at ../examples/ipsec-secgw/ipsec_process.c:89 > > #7 0x0000561752f0d7dd in ipsec_process ( > > ctx=3D0x56175aa6a210 , trf=3D0x7ffd192326a0) > > at ../examples/ipsec-secgw/ipsec_process.c:300 > > #8 0x0000561752f21027 in process_pkts_outbound ( > > --Type for more, q to quit, c to continue without paging-- > > ipsec_ctx=3D0x56175aa6a210 , > > traffic=3D0x7ffd192326a0) > > at ../examples/ipsec-secgw/ipsec-secgw.c:839 > > #9 0x0000561752f21b2e in process_pkts ( > > qconf=3D0x56175aa57340 , pkts=3D0x7ffd19233c20, > > nb_pkts=3D1 '\001', portid=3D1) at ../examples/ipsec-secgw/ipsec-se= cgw.c:1072 > > #10 0x0000561752f224db in ipsec_poll_mode_worker () > > at ../examples/ipsec-secgw/ipsec-secgw.c:1262 > > #11 0x0000561752f38adc in ipsec_launch_one_lcore (args=3D0x56175c549700= ) > > at ../examples/ipsec-secgw/ipsec_worker.c:654 > > #12 0x0000561753cbc523 in rte_eal_mp_remote_launch ( > > f=3D0x561752f38ab5 , arg=3D0x56175c549700, > > call_main=3DCALL_MAIN) at ../lib/eal/common/eal_common_launch.c:64 > > #13 0x0000561752f265ed in main (argc=3D12, argv=3D0x7ffd19234168) > > at ../examples/ipsec-secgw/ipsec-secgw.c:2978 > > (gdb) frame 2 > > #2 0x0000561757073753 in aesni_gcm_session_configure > > (mb_mgr=3D0x56175c5fe400, > > session=3D0x17e3b72d8, xform=3D0x17e05d7c0) > > at ../drivers/crypto/ipsec_mb/pmd_aesni_gcm.c:132 > > 132 mb_mgr->gcm128_pre(key, &sess->gdata_key); > > > > Because of un-expected unaligned memory access: > > (gdb) disas > > Dump of assembler code for function aes_keyexp_128_enc_avx512: > > 0x00007ff9274f400b <+0>: endbr64 > > 0x00007ff9274f400f <+4>: cmp $0x0,%rdi > > 0x00007ff9274f4013 <+8>: je 0x7ff9274f41b4 > > > > 0x00007ff9274f4019 <+14>: cmp $0x0,%rsi > > 0x00007ff9274f401d <+18>: je 0x7ff9274f41b4 > > > > 0x00007ff9274f4023 <+24>: vmovdqu (%rdi),%xmm1 > > =3D> 0x00007ff9274f4027 <+28>: vmovdqa %xmm1,(%rsi) > > > > (gdb) print/x $rsi > > $12 =3D 0x17e3b72e8 > > > > And this is caused because now AES_GCM session private data is not 16B-= bits > > aligned anymore: > > (gdb) print ((struct aesni_gcm_session *)sess->sess_data[index].data) > > $29 =3D (struct aesni_gcm_session *) 0x17e3b72d8 > > > > print &((struct aesni_gcm_session *)sess->sess_data[index].data)- > > >gdata_key > > $31 =3D (struct gcm_key_data *) 0x17e3b72e8 > > > > As I understand the reason for that is that we changed the way how > > sess_data[index].data > > is populated. Now it is just: > > sess->sess_data[index].data =3D (void *)((uint8_t *)sess + > > rte_cryptodev_sym_get_header_session_si= ze() + > > (index * sess->priv_sz)); > > > > So, as I can see, there is no guarantee that PMD's private sess data wi= ll be > > aligned on 16B > > as expected. > > > Agreed, that there is no guarantee that the sess_priv will be aligned. > I believe this is requirement from the PMD side for a particular alignmen= t. Yes, it is PMD specific requirement. The problem is that with new approach you proposed there is no simple way f= or PMD to fulfil that requirement. In current version of DPDK: - PMD reports size of private data, note that it reports extra space needed to align its data properly inside provided buffer. - Then it ss up to higher layer to allocate mempool with elements big enoug= h to hold=20 PMD private data. - At session init that mempool is passed to PMD sym_session_confgure() and = it is=20 PMD responsibility to allocate buffer (from given mempool) for its private= data align it properly, and update sess->sess_data[].data. With this patch: - PMD still reports size of private data, but now it is cryptodev layer w= ho allocates memory for PMD private data and updates sess->sess_data[].data. =20 So PMD simply has no way to allocate/align its private data in a way it lik= es to. Of course it can simply do alignment on the fly for each operation, somethi= ng like: void *p =3D get_sym_session_private_data(sess, dev->driver_id); sess_priv =3D RTE_PTR_ALIGN_FLOOR(p, PMD_SES_ALIGN); But it is way too ugly and error-prone.=20 Another potential problem with that approach (when cryptodev allocates memo= ry for=20 PMD private session data and updates sess->sess_data[].data for it) - it co= uld happen that private data for different PMDs can endup on the same cache-line.=20 If we'll ever have a case with simultaneous session processing by multiple-= devices it can cause all sorts of performance problems. All in all - these changes for (remove second mempool, change the way we al= locate/setup session private data) seems premature to me. So, I think to go ahead with this series (hiding rte_cryptodev_sym_session)= for 21.11 we need to drop changes for sess_data[] management allocation and keep only= changes directly related to hide sym_session. =20 My apologies for not reviewing/testing properly that series earlier. > Is it possible for the PMD to use __rte_aligned for the fields which are = required to The data structure inside PMD is properly aligned. The problem is that now cryptodev layer might provide to PMD memory that is= not properly aligned. > Be aligned. For aesni_gcm it is 16B aligned requirement, for some other P= MD it may be > 64B alignment.