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 29C35A0547; Thu, 21 Oct 2021 10:43:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 14148411BE; Thu, 21 Oct 2021 10:43:44 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id B1746411BB for ; Thu, 21 Oct 2021 10:43:41 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10143"; a="315184977" X-IronPort-AV: E=Sophos;i="5.87,169,1631602800"; d="scan'208";a="315184977" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Oct 2021 01:43:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,169,1631602800"; d="scan'208";a="463544203" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orsmga002.jf.intel.com with ESMTP; 21 Oct 2021 01:43:40 -0700 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) by ORSMSX603.amr.corp.intel.com (10.22.229.16) 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 01:43:40 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX607.amr.corp.intel.com (10.22.229.20) 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 01:43:39 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) 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.2242.12 via Frontend Transport; Thu, 21 Oct 2021 01:43:39 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.102) by edgegateway.intel.com (134.134.137.100) 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 01:43:39 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hAYIMtouM0N4OGsOd5Kl+A6u6tkdmIjVQRzEct3yCm8gB/aEnPcJ5EeWEVyob9gsTj03CyimN4QR/L0zHlSkSSvwRFeSdj4Lb2idFZP/tT70xWf+eyEQH12NwV+/2K6Gv0/GG/bAv5LqH2xr1QQgxc/chdLFJxSVM1InfhIGB/58kCTRCZHbif79D60N0N36Itr7P2qEvskqsMdT88Tg3SAE4HEDyB+hI6w62R1sT5sIGnuugGPDHV66Fs0hJfoEGBoCUKqDu2NvoBEsD4NWTK5T1a/W5KM2lBG92jNKr0pf2BjuvX6LO8DqXm8giCR0xEChxKaINTsoU7lW1THzKA== 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=1eeKTtMaVKOYZ0AI0MbMkZaqOP45G+ZL6XfOn3IQR3E=; b=YfEJJJAW0q8vrJrBAwqzXAC0jc8l20XHTdHRcYqyVqyqoPZfPN125iHXn0dPEA7HQYgmgFgoWbb/4Z6OR0WLdx6MVk8hXO+aRZ4o5w227mN6ZmmoPqoXW0R6UwG2ijOjgtWZcBB5+EB29xBiZOYHro6Qbj4d4QOhsgze3J9KedieWjqU6dmDnelUXbP5cMi/jBaOcLRDc8sWVF8zyhJz906bKZTOgZklh+Dp/U0iNYQiBKN34K6psiADh6oBZyCvVBSlbHJswQe9EY4Ynz+O+ETbcOrHpuIo93X4QfHPdhA2P0s2lJQ7JxtMZk6YQ3zPkQdYkEM/GCNAkyNolOZjUg== 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=1eeKTtMaVKOYZ0AI0MbMkZaqOP45G+ZL6XfOn3IQR3E=; b=fWkgDmjG/3E6sXQBA1KHNyQVvLjBnXchqUg6KlRz8kigFZrzPa1tjkLeqmkdm9PzCY8irvPgUfmsstRM1Bizw9V0UzgPE0uUOn2V6Zqpf3zCXkG8U++hyuJBpXtxsWEpfifwVBDCTe3+kjmEhElXP3pWb+F8ZOxkTMxdOsC8Am0= Received: from MW5PR11MB5809.namprd11.prod.outlook.com (2603:10b6:303:197::6) by CO1PR11MB5124.namprd11.prod.outlook.com (2603:10b6:303:94::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.17; Thu, 21 Oct 2021 08:43:38 +0000 Received: from MW5PR11MB5809.namprd11.prod.outlook.com ([fe80::2c31:1470:3036:959b]) by MW5PR11MB5809.namprd11.prod.outlook.com ([fe80::2c31:1470:3036:959b%7]) with mapi id 15.20.4628.018; Thu, 21 Oct 2021 08:43:38 +0000 From: "Zhang, Roy Fan" To: Akhil Goyal , "Power, Ciara" , "dev@dpdk.org" , "Ananyev, Konstantin" , "thomas@monjalon.net" , "De Lara Guarch, Pablo" CC: "david.marchand@redhat.com" , "hemant.agrawal@nxp.com" , Anoob Joseph , "Trahe, Fiona" , "Doherty, Declan" , "matan@nvidia.com" , "g.singh@nxp.com" , "jianjay.zhou@huawei.com" , "asomalap@amd.com" , "ruifeng.wang@arm.com" , "Nicolau, Radu" , "ajit.khaparde@broadcom.com" , Nagadheeraj Rottela , Ankur Dwivedi , "Wang, Haiyue" , "jiawenwu@trustnetic.com" , "jianwang@trustnetic.com" , "Jerin Jacob Kollanukkaran" , Nithin Kumar Dabilpuram Thread-Topic: [PATCH v3 0/8] crypto/security session framework rework Thread-Index: AQHXxGgUi0ShiSiwI0WEIc9XeNkXdqvcClMAgAAPjYCAAAHsAIAAFU8AgADypaA= Date: Thu, 21 Oct 2021 08:43:38 +0000 Message-ID: References: <20211013192222.1582631-2-gakhil@marvell.com> <20211018213452.2734720-1-gakhil@marvell.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.6.200.16 dlp-reaction: no-action dlp-product: dlpe-windows 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: fa85caf9-7906-4c52-6097-08d9946ee077 x-ms-traffictypediagnostic: CO1PR11MB5124: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: k7SjHWuv8Z0lDhU0nrbpvi6l8mkCv10srhtcC4sMrincrofoxRmGF78+R9o8Gf4Ca7E9HFmeQ3asgXlwyrWplZOArvFzqKpvaDtVsNsrf/aMP2joVkBVjAL3RNK5CL3uyJzEnmb4GkYWDBFIpNNVJXpZskyai1U6PPSZ4qT0q9FFDfwU4muwnS4JbJWMYI4KGXrFLtIezju2dUjwBIPpcdM2btcszUuxp3bmzDjsGZbWFdYeeDZH/lsSbiHE9GCKEzm3kc5Lm60rVcGXyK/afs/+ZNXQWy5y1Otvuz7jA832X/cA+/4cEg7rmGMJR2xms6t26J8JsvGUSq92TbzHY5Lk8jvBR5TcuJdkfHYjEwtE1jEFqnfpWEZK0EziAeNdem6m+Y8UJueVZDLeheZVhApTs4LbFxgEcy1n9QUNs7bzOxK6fIjuVsvBG/VVfvlG+Wkkb4isBi57egaWfFHSr1IwM9nJPbjE9o3DPyjOMLarTRsJpqbJ4kShq1vb6/4Sksit0ESUsZmwk45jJVB8nggBlxPV7dqMzu7Jy7z7rGDEsCGs65VFJaY6cxhRsqAwf2zXmqf2RYQws88cPCp3yLPbHZJw1s5bu84uvXo5Na7vWzaYJgwPCGsBNtUajZS8ci9vHOKn9NVABgqs1+OeimxGsHlZUQ4icz81t64hBV1VCfS9s7VKfBIrfjBUIxMEAqAcqKhMDXbCheK+yRBkwQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW5PR11MB5809.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(15650500001)(2906002)(71200400001)(5660300002)(54906003)(66556008)(316002)(64756008)(86362001)(52536014)(186003)(66446008)(55016002)(6506007)(4326008)(53546011)(7416002)(7696005)(8936002)(9686003)(26005)(8676002)(6636002)(110136005)(508600001)(83380400001)(66946007)(38070700005)(122000001)(38100700002)(82960400001)(33656002)(66476007)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?NATAQ8IvMSQ2SlgSrMx+f/cMZ74TdTofun1pEgugDkxyA6EAIKS7ooan?= =?Windows-1252?Q?q8W5uEi5HOGUn4UEgnbBCTy11vIjh9PPFBeIQz1QAkYWNbB+9oAKHk+W?= =?Windows-1252?Q?Xv53YoENz9d23HSBgpIe+i8fYZSEofVd7eQUZ9F/Sln0zijKZHEO0Amg?= =?Windows-1252?Q?rvdkB7dUwiafzU3rNBuF/WWNsGv+NMDrkYtmDUtADHELgUzg3T0p9NMV?= =?Windows-1252?Q?69vNMMVjUn5MmZ2S+x1eAjD/2dhIoO3vCLFCxnXCp3+w7i/pe8HbOCyV?= =?Windows-1252?Q?AYIr9SrIG5z0PJhpokSdEOgiBdTE42pgs72ggOwcC9O1F1gQd+OrLohU?= =?Windows-1252?Q?axPUZii8tSWxzkfk6FBlbKxyIt0oVi/I2o12xOMBuwbDJoEWtuGrUDo4?= =?Windows-1252?Q?NwYwdxEJTKVEPqPddsxpjE+nQ87+m2JY+1LVKQBar58giEWXukzkMAdX?= =?Windows-1252?Q?3B0DZn4ZQ1+aTLY0vZBz4kgPVTAQlnpFmH1PRoEZYK3JDDIN0bkjOzQP?= =?Windows-1252?Q?2QPfhIgbDMEbhdVZAvXXjTq6XFLhCxoAy3vkzyIuESsHolfCIzhuINB5?= =?Windows-1252?Q?6+xnV9A6C1lL5w6egglk1RE/esqsvGsjW47WILtZR2IsSzlAQqaWWOd2?= =?Windows-1252?Q?aEBQYQ68NMt7C41paK7gGmdGHYhYtDMTWJ3idlXgG8Yk5lw8s2PreW0a?= =?Windows-1252?Q?xf+aBfRTahHMAN6NMk4rA+PqxnD1M9hZ286UEmL5MLpLzxq/mFYaTpVV?= =?Windows-1252?Q?BP1Km+/ERh8jX/4tXRm+RBqHABXreX1Fb7QqivuVjM63i749J8yxCVTX?= =?Windows-1252?Q?jCM5bh8wdfIgR6O4SbKYdFbvh0F8/tf/aWiBHewjnVhEA/AxflL+TTt7?= =?Windows-1252?Q?75u5n57QpY3wspJe6QPDRXDSQBnB6H5OBtBbwccXvbGvRFSjzQE2EG1Z?= =?Windows-1252?Q?jIqJ05mtCT8u0UXNAVHYZ/e66sW1gVyzaEru9TU9oGxrKupQRaKpBYtI?= =?Windows-1252?Q?YkQma09k0Li5GF92yEbM9JIs3s1bXal79a8fS7B1E9bup+FS6v2TI+Fr?= =?Windows-1252?Q?Hc5NcpzQeQfLDK1wcv++0Ulhb/GTmTkYUcHvd+t7uomIInR7ijk3xPel?= =?Windows-1252?Q?rTT9k76YXWDB4VGIgNLJQJwH3EtRcRK23PmD2fr5sSMA/DEyTtStybAA?= =?Windows-1252?Q?bpaOKtV5k0ImHiq9Oh1kSq74dWBwJXRJEMRuSr11opZLQPFU999w9aIF?= =?Windows-1252?Q?iBvu16O+sVSbykh/fTQhJEvC1avhmpfLWRPTHaA1A9fCpr6sYv4iKyrP?= =?Windows-1252?Q?Byp5jAfQof9UH6W6u3r9mqlp+JhOhZJGjPMN0nQyaAejJ9nsRZI3KV6p?= =?Windows-1252?Q?9gwERJkbpID4YvH+BIj+/GzJcCkF1vFbI4rjmy6SdCm3hnaF+GOUXkCJ?= 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: MW5PR11MB5809.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa85caf9-7906-4c52-6097-08d9946ee077 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2021 08:43:38.1584 (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: roy.fan.zhang@intel.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5124 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v3 0/8] crypto/security session framework rework 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" Hi Akhil, > -----Original Message----- > From: Akhil Goyal > Sent: Wednesday, October 20, 2021 7:05 PM > To: Power, Ciara ; dev@dpdk.org; Ananyev, > Konstantin ; thomas@monjalon.net; Zhang, > Roy Fan ; De Lara Guarch, Pablo > > Cc: david.marchand@redhat.com; hemant.agrawal@nxp.com; Anoob Joseph > ; Trahe, Fiona ; Doherty, > Declan ; matan@nvidia.com; g.singh@nxp.com; > jianjay.zhou@huawei.com; asomalap@amd.com; ruifeng.wang@arm.com; > Nicolau, Radu ; ajit.khaparde@broadcom.com; > Nagadheeraj Rottela ; Ankur Dwivedi > ; Wang, Haiyue ; > jiawenwu@trustnetic.com; jianwang@trustnetic.com; Jerin Jacob > Kollanukkaran ; Nithin Kumar Dabilpuram > > Subject: RE: [PATCH v3 0/8] crypto/security session framework rework >=20 > > > > I am seeing test failures for cryptodev_scheduler_autotest: > > > > + Tests Total : 638 > > > > + Tests Skipped : 280 > > > > + Tests Executed : 638 > > > > + Tests Unsupported: 0 > > > > + Tests Passed : 18 > > > > + Tests Failed : 340 > > > > > > > > The error showing for each testcase: > > > > scheduler_pmd_sym_session_configure() line 487: unable to config > sym > > > > session > > > > CRYPTODEV: rte_cryptodev_sym_session_init() line 1743: dev_id 2 > failed > > to > > > > configure session details > > > > > > > > I believe the problem happens in > > scheduler_pmd_sym_session_configure. > > > > The full sess object is no longer accessible in here, but it is req= uired to > be > > > > passed to rte_cryptodev_sym_session_init. > > > > The init function expects access to sess rather than the private da= ta, > and > > > now > > > > fails as a result. > > > > > > > > static int > > > > scheduler_pmd_sym_session_configure(struct rte_cryptodev *dev, > > > > struct rte_crypto_sym_xform *xform, void *sess, > > > > rte_iova_t sess_iova __rte_unused) > > > > { > > > > struct scheduler_ctx *sched_ctx =3D dev->data->dev_private; > > > > uint32_t i; > > > > int ret; > > > > for (i =3D 0; i < sched_ctx->nb_workers; i++) { > > > > struct scheduler_worker *worker =3D &sched_ctx->wor= kers[i]; > > > > ret =3D rte_cryptodev_sym_session_init(worker->dev_= id, sess, > > > > xform); > > > > if (ret < 0) { > > > > CR_SCHED_LOG(ERR, "unable to config sym ses= sion"); > > > > return ret; > > > > } > > > > } > > > > return 0; > > > > } > > > > > > > It looks like scheduler PMD is managing the stuff on its own for othe= r > > PMDs. > > > The APIs are designed such that the app can call session_init multipl= e > times > > > With different dev_id on same sess. > > > But here scheduler PMD internally want to configure other PMDs > sess_priv > > > By calling session_init. > > > > > > I wonder, why we have this 2 step session_create and session_init? > > > Why can't we have it similar to security session create and let the > scheduler > > > PMD have its big session private data which can hold priv_data of as = many > > > PMDs > > > as it want to schedule. > > > > > > Konstantin/Fan/Pablo what are your thoughts on this issue? > > > Can we resolve this issue at priority in RC1(or probably RC2) for thi= s > release > > > or > > > else we defer it for next ABI break release? > > > > > > Thomas, > > > Can we defer this for RC2? It does not seem to be fixed in 1 day. > > > > On another thought, this can be fixed with current patch also by having= a > big > > session > > Private data for scheduler PMD which is big enough to hold all other PM= Ds > > data which > > it want to schedule and then call the sess_configure function pointer o= f dev > > directly. > > What say? And this PMD change can be done in RC2. And this patchset go > as > > is in RC1. > Here is the diff in scheduler PMD which should fix this issue in current > patchset. >=20 > diff --git a/drivers/crypto/scheduler/scheduler_pmd_ops.c > b/drivers/crypto/scheduler/scheduler_pmd_ops.c > index b92ffd6026..0611ea2c6a 100644 > --- a/drivers/crypto/scheduler/scheduler_pmd_ops.c > +++ b/drivers/crypto/scheduler/scheduler_pmd_ops.c > @@ -450,9 +450,8 @@ scheduler_pmd_qp_setup(struct rte_cryptodev *dev, > uint16_t qp_id, > } >=20 > static uint32_t > -scheduler_pmd_sym_session_get_size(struct rte_cryptodev *dev > __rte_unused) > +get_max_session_priv_size(struct scheduler_ctx *sched_ctx) > { > - struct scheduler_ctx *sched_ctx =3D dev->data->dev_private; > uint8_t i =3D 0; > uint32_t max_priv_sess_size =3D 0; >=20 > @@ -469,20 +468,35 @@ scheduler_pmd_sym_session_get_size(struct > rte_cryptodev *dev __rte_unused) > return max_priv_sess_size; > } >=20 > +static uint32_t > +scheduler_pmd_sym_session_get_size(struct rte_cryptodev *dev) > +{ > + struct scheduler_ctx *sched_ctx =3D dev->data->dev_private; > + > + return get_max_session_priv_size(sched_ctx) * sched_ctx- > >nb_workers; > +} > + > static int > scheduler_pmd_sym_session_configure(struct rte_cryptodev *dev, > struct rte_crypto_sym_xform *xform, void *sess, > rte_iova_t sess_iova __rte_unused) > { > struct scheduler_ctx *sched_ctx =3D dev->data->dev_private; > + uint32_t worker_sess_priv_sz =3D get_max_session_priv_size(sched_= ctx); > uint32_t i; > int ret; >=20 > for (i =3D 0; i < sched_ctx->nb_workers; i++) { > struct scheduler_worker *worker =3D &sched_ctx->workers[i= ]; > + struct rte_cryptodev *worker_dev =3D > + rte_cryptodev_pmd_get_dev(worker->dev_id)= ; > + uint8_t index =3D worker_dev->driver_id; >=20 > - ret =3D rte_cryptodev_sym_session_init(worker->dev_id, se= ss, > - xform); > + ret =3D worker_dev->dev_ops->sym_session_configure( > + worker_dev, > + xform, > + (uint8_t *)sess + (index * worker_sess_pr= iv_sz), > + sess_iova + (index * worker_sess_priv_sz)= ); This won't work. This will make the session configuration finish successful= ly but the private data the worker initialized is not the private data the w= orker will use during enqueue/dequeue (workers only uses the session private data based on its driver id). > if (ret < 0) { > CR_SCHED_LOG(ERR, "unable to config sym session")= ; > return ret;