From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55EA1C4321A for ; Fri, 28 Jun 2019 07:04:07 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id A9921204EC for ; Fri, 28 Jun 2019 07:04:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=marvell.com header.i=@marvell.com header.b="GV69RwCP"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=marvell.onmicrosoft.com header.i=@marvell.onmicrosoft.com header.b="wJyI5WE6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A9921204EC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=marvell.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0E6D41B99F; Fri, 28 Jun 2019 09:04:05 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id D10B31B99E for ; Fri, 28 Jun 2019 09:04:03 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5S71sk3019449; Fri, 28 Jun 2019 00:04:02 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=vM8R0FlKBlF/B7p+0bf8ZDgJ8PM5b/AIds5wa22lHHE=; b=GV69RwCPROgdUek9+v77ompG1JuHOx1rJlsqGPkA7CkmYrpeqt+Vvbgp+8Gi+8xONIHW diZk9BVJVxhhsTNwxzqtIX7y+MjwgQM2V4DKczoEAgnh7qQTcBhh/23coAefQ6IEIiGc USchOnCW4fIRAAfK4YBSthueGk4iLivd5y0E+BDThL/X69t0TIPZfcKhpG5bM3NBD9xr sPzjX/qbOXMaKHhOzmOfwDO+avr7/xGv8sg6SN+tpU2cATGDB3gV1ZwqBsQawsWpZNY8 +jwMePT54ET/v4UChK2pBFQSez5P/+EB+n6M21+iQPW8N+x7UlOzyVDraHwClUvA4ou1 Ng== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 2tcvnhc2a6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 28 Jun 2019 00:04:02 -0700 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 28 Jun 2019 00:04:00 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (104.47.40.58) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Fri, 28 Jun 2019 00:04:00 -0700 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=wgcyJa9Hinpp732ReDKnP+jwjRWIBiFBsU84faUVjPesQOY1FYVxvsn/hCCDxUY+EYlKLRJE82sJVK4Gh1pwku/hb0EzoiADnqjz6h4dUVygFi+UPO5leldzMKnrOEzh0Fr0F1eOThlCrCWFa0hDlIWe2oe/GA4G5w+gjExyUyQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vM8R0FlKBlF/B7p+0bf8ZDgJ8PM5b/AIds5wa22lHHE=; b=bPAtQD/PhiikfS6stGjA7dCma5h9N9vjGjuM+Fd7mSw+7T2otnnhv1U6svdOxXq972rWRkCO399hRYdNHuyShpzHqK9Ct+vVr7NIgX3u9fFzqVgfn15yYibj5QzMEB3NJCDLQ/lQyngm1hXCzQolL8ErDVPjG0ddGcP7j0EP/Ro= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vM8R0FlKBlF/B7p+0bf8ZDgJ8PM5b/AIds5wa22lHHE=; b=wJyI5WE6DHoQPb/hXH/u0Ir7K8VLacGXzQ1otHN1AHRoH/wBgW7NSTYOzpLqHmZb9mFXTHWAyzUpu/WHrbTkBLiM8AM2R31/Z44BNBbzkbDjcX/y4wp4fsW57iTOCeOE2abN8uhdnnlbsmRxvakDJHbc5ueoj3DfgZjmJbz+2pY= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB2782.namprd18.prod.outlook.com (20.179.21.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Fri, 28 Jun 2019 07:03:56 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::595e:3b6c:3d12:7285]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::595e:3b6c:3d12:7285%7]) with mapi id 15.20.2008.018; Fri, 28 Jun 2019 07:03:56 +0000 From: Anoob Joseph To: Akhil Goyal , Junxiao Shi , "dev@dpdk.org" CC: "De Lara Guarch, Pablo" Thread-Topic: [EXT] [dpdk-dev] [PATCH] cryptodev: free memzone when releasing cryptodev Thread-Index: AQHVFw4cNLSHOgvaXkOoczdMlBQKZKawtzYggAAMUoCAAAeX0A== Date: Fri, 28 Jun 2019 07:03:56 +0000 Message-ID: References: <201905301724.x4UHOJN7016223@lectura.cs.arizona.edu> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [115.113.156.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 09bc9622-c47f-419a-fe98-08d6fb96c99d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR18MB2782; x-ms-traffictypediagnostic: MN2PR18MB2782: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:873; x-forefront-prvs: 00826B6158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(396003)(39860400002)(366004)(13464003)(189003)(199004)(478600001)(6246003)(9686003)(6306002)(55016002)(7736002)(81156014)(8676002)(8936002)(81166006)(76116006)(66476007)(73956011)(2906002)(6436002)(86362001)(229853002)(4326008)(66946007)(68736007)(64756008)(66556008)(5660300002)(305945005)(66446008)(53936002)(52536014)(74316002)(2501003)(53546011)(55236004)(33656002)(5024004)(316002)(71200400001)(186003)(71190400001)(6506007)(14454004)(66066001)(26005)(256004)(102836004)(14444005)(99286004)(476003)(966005)(11346002)(446003)(110136005)(25786009)(3846002)(6116002)(7696005)(76176011)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB2782; H:MN2PR18MB2877.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TMhVG9kUOnWK4XX59XInzJQGyu+m3P828GR6IZu4WX13Mh3e7f011hmlzrjzKFL2t+KvVhfpdJZvOs76OtqjCHMEWShOCICc1wsg1ZmUIDGRfTifDiUfR7jloEn0p88EkWnCi7R0I3tWS3v9U8mYQUFauJC7rzye6Wfj0qJGeAIsxEhNjMCX/lZzw5ICcHiIRGZ0TqEEElyFCgiNx7Iva+Svx0PWvMh26uJi4eqxzJ8ehmEOVlgLeG9IO+/TrJF8SxclTjjGy4hpHXXmKjFOBaJcgqICDbzVmfy7tjReWYCksM/EKKVE8wcSh9rkXNP28n6+Fwdnq80AHyP5Q+SWVLHZUDqYzm/y1WHSvmUN8IXqSBYJNG7ZEdUYteGywGOAHEGEfTz/Ilym8MmuwqjGIvS3Eo0LCx3CItU7mu+fKa0= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 09bc9622-c47f-419a-fe98-08d6fb96c99d X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2019 07:03:56.3675 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: anoobj@marvell.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB2782 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-28_02:, , signatures=0 Subject: Re: [dpdk-dev] [EXT] [PATCH] cryptodev: free memzone when releasing cryptodev 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, Please see inline. Thanks, Anoob > -----Original Message----- > From: Akhil Goyal > Sent: Friday, June 28, 2019 11:45 AM > To: Anoob Joseph ; Junxiao Shi > ; dev@dpdk.org > Cc: De Lara Guarch, Pablo > Subject: RE: [EXT] [dpdk-dev] [PATCH] cryptodev: free memzone when > releasing cryptodev >=20 > Hi Anoob, > > > > > > -------------------------------------------------------------------- > > > -- When a cryptodev is created in a primary process, > > > rte_cryptodev_data_alloc reserves a memzone. > > > However, this memzone was not released when the cryptodev is > uninitialized. > > > After that, new cryptodev cannot be created due to memzone name > conflict. > > > > > > This commit frees the memzone when a cryptodev is uninitialized, > > > fixing this bug. This approach is chosen instead of keeping and > > > reusing the old memzone, because the new cryptodev could belong to a > different NUMA socket. > > > > > > Also, rte_cryptodev_data pointer is now properly recorded in > > > cryptodev_globals.data array. > > > > > > Bugzilla ID: 105 > > > > > > Signed-off-by: Junxiao Shi > > > --- > > > lib/librte_cryptodev/rte_cryptodev.c | 44 > > > +++++++++++++++++++++++++++++++----- > > > 1 file changed, 38 insertions(+), 6 deletions(-) > > > > > > diff --git a/lib/librte_cryptodev/rte_cryptodev.c > > > b/lib/librte_cryptodev/rte_cryptodev.c > > > index 00c2cf4..666dfea 100644 > > > --- a/lib/librte_cryptodev/rte_cryptodev.c > > > +++ b/lib/librte_cryptodev/rte_cryptodev.c > > > @@ -653,6 +653,31 @@ rte_cryptodev_data_alloc(uint8_t dev_id, struct > > > rte_cryptodev_data **data, > > > return 0; > > > } > > > > > > +static inline int > > > +rte_cryptodev_data_free(uint8_t dev_id, struct rte_cryptodev_data > > > +**data) { > > > + char mz_name[RTE_CRYPTODEV_NAME_MAX_LEN]; [Anoob] Shouldn't we use RTE_MEMZONE_NAMESIZE instead? I guess this is also= coming from the existing code in rte_cryptodev_data_alloc(). May be we sho= uld fix that as well? =20 > > > + const struct rte_memzone *mz; > > > + int n; > > > + > > > + /* generate memzone name */ > > > + n =3D snprintf(mz_name, sizeof(mz_name), > "rte_cryptodev_data_%u", > > > dev_id); > > > + if (n >=3D (int)sizeof(mz_name)) > > > + return -EINVAL; > > > > [Anoob] Is the above check needed? > I believe this being used while creating the memzone, so same logic is us= ed > while freeing it. > Just to be safe. >=20 [Anoob] Thinking bit more, it seems like we are trying to capture a situati= on when the name is getting truncated because of insufficient buffer space.= So it is safe to have I guess. But even in that case, 'n' will not be grea= ter than the "size" field passed (which happens to be sizeof(mz_name) in ou= r case). My opinion is '=3D=3D' might make more sense. But I leave that to your judg= ement.=20 =20 > > > > > + > > > + mz =3D rte_memzone_lookup(mz_name); > > > + if (mz =3D=3D NULL) > > > + return -ENOMEM; > > > > [Anoob] Is the return value correct? Shouldn't it be -EINVAL? > > > > @Akhil, thoughts? >=20 >=20 > I believe ENOMEM is correct, as there is no memory associated with the > cryptodev_data. [Anoob] Agreed. >=20 > > > > > + > > > + RTE_ASSERT(*data =3D=3D mz->addr); > > > + *data =3D NULL; > > > + > > > + if (rte_eal_process_type() =3D=3D RTE_PROC_PRIMARY) > > > + return rte_memzone_free(mz); > > > + > > > + return 0; > > > +} > > > + > > > static uint8_t > > > rte_cryptodev_find_free_device_index(void) > > > { > > > @@ -687,16 +712,16 @@ rte_cryptodev_pmd_allocate(const char > *name, > > > int > > > socket_id) > > > cryptodev =3D rte_cryptodev_pmd_get_dev(dev_id); > > > > > > if (cryptodev->data =3D=3D NULL) { > > > - struct rte_cryptodev_data *cryptodev_data =3D > > > - cryptodev_globals.data[dev_id]; > > > + struct rte_cryptodev_data **cryptodev_data =3D > > > + &cryptodev_globals.data[dev_id]; > > > > > > - int retval =3D rte_cryptodev_data_alloc(dev_id, > &cryptodev_data, > > > + int retval =3D rte_cryptodev_data_alloc(dev_id, > cryptodev_data, > > > socket_id); > > > > > > - if (retval < 0 || cryptodev_data =3D=3D NULL) > > > + if (retval < 0 || *cryptodev_data =3D=3D NULL) > > > return NULL; > > > > > > - cryptodev->data =3D cryptodev_data; > > > + cryptodev->data =3D *cryptodev_data; > > > > > > strlcpy(cryptodev->data->name, name, > > > RTE_CRYPTODEV_NAME_MAX_LEN); > > > @@ -724,13 +749,20 @@ rte_cryptodev_pmd_release_device(struct > > > rte_cryptodev *cryptodev) > > > if (cryptodev =3D=3D NULL) > > > return -EINVAL; > > > > > > + uint8_t dev_id =3D cryptodev->data->dev_id; > > > + > > > > [Anoob] Variables need to be declared at the start of the function. > > https://doc.dpdk.org/guides/contributing/coding_style.html > > > > > /* Close device only if device operations have been set */ > > > if (cryptodev->dev_ops) { > > > - ret =3D rte_cryptodev_close(cryptodev->data->dev_id); > > > + ret =3D rte_cryptodev_close(dev_id); > > > if (ret < 0) > > > return ret; > > > } > > > > > > + struct rte_cryptodev_data **cryptodev_data =3D > > > &cryptodev_globals.data[dev_id]; > > > > [Anoob] Same comment as above > > > > > + ret =3D rte_cryptodev_data_free(dev_id, cryptodev_data); > > > + if (ret < 0) > > > + return ret; > > > + > > > cryptodev->attached =3D RTE_CRYPTODEV_DETACHED; > > > cryptodev_globals.nb_devs--; > > > return 0; > > > -- > > > 2.7.4