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 A71ADA0093; Tue, 4 Jan 2022 18:29:02 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 34C0C40042; Tue, 4 Jan 2022 18:29:02 +0100 (CET) Received: from mail1.bemta32.messagelabs.com (mail1.bemta32.messagelabs.com [195.245.230.2]) by mails.dpdk.org (Postfix) with ESMTP id 0CCFC40040 for ; Tue, 4 Jan 2022 18:29:01 +0100 (CET) Received: from [100.115.6.48] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-a.eu-west-1.aws.ess.symcld.net id B9/41-10124-CD384D16; Tue, 04 Jan 2022 17:29:00 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFJsWRWlGSWpSXmKPExsWSoc9jpHu7+Uq iweTbFhbvPm1ncmD0+LVgKWsAYxRrZl5SfkUCa0bTjc2sBb+bGCuaDs5gaWDcXNrFyMXBKLCU WeLGpqksEM4iVolfW/ezQTh7GCVu/mgDc1gEtjJL/FtxCKxMSGAuk8Tsl3uYIZxHjBKrZt4Hy nBysAmYSLza28wEYosIZEmcufSAFcRmFlCU+LRgEliNsICexKtn69khavQljh+ZxAZhO0n0H9 oNFOcAWqcicW17EkiYVyBRYsmizYwQu64zSky71gvWyykQJ7Ftz0Qwm1FAVuJL42pmiF3iEre ezAe7QUJAQGLJnvPMELaoxMvH/1gh6iskPsxYBlUjK3FpfjcjhO0rsfbWdBYIW1fi6Yq/UL05 EqtfTmOHsNUkbrzpgIrLSazqfQhVLy8xbdF7qBoZiQc3toODTkLgD6tEa/N9KKeDReLg3ROsE FUGEvO+HWGbwKg7C8nhs4ABwCyQJ/H5ROAscAAISpyc+YQFokRHYsHuT2wQtrbEsoWvmWHsMw ceMyGLL2BkX8VolVSUmZ5RkpuYmaNraGCga2hoqmsCZBnqJVbpJuqlluqWpxaX6AK55cV6qcX FesWVuck5KXp5qSWbGIEJK6WYJXUHY1/fT71DjJIcTEqivD9triQK8SXlp1RmJBZnxBeV5qQW H2KU4eBQkuB90giUEyxKTU+tSMvMASZPmLQEB4+SCG9VE1Cat7ggMbc4Mx0idYrRm2PCy7mLm Dm6ehYCyY+rlgDJ72Dy5nsQOenI7u3MQix5+XmpUuK8nSAjBEBGZJTmwS2AZYFLjLJSwryMDA wMQjwFqUW5mSWo8q8YxTkYlYR5I0Gm8GTmlcDd8QroRCagE8/JXQY5sSQRISXVwLRLofGaz0O GP/fnzEp5+GZaYXmMsL3LaRcpteVvFAzU50budzieIynte3/veyXjxc5bOJaZpsdNmu+7lWXu D5clwieWfM363PHKuefAu96n+S3LMhdyms9METzCUD2zzU7W7Ce7eGLStIdb7gfFbbc6YiFbx Kmu+TljwlEbr0z140tcH+8sTlqwtPXh/DTLgEtH/HxeFvFNlr7+fOWpmobvOVsdlYpPH6nkj8 v7yCm94bZTnOWfGdElvIt9Zxw577Vz3SUHt+emj7ki1TW3zHu4IGc/U13170uO7+Kmr/FndE4 R/CFzuOa95KX18+/d1LF7nTQvcWL1BaY5ck6xFw48bGS/EvtmoauJ/7xbL+qUWIozEg21mIuK EwG3es0GfQQAAA== X-Env-Sender: John.Alexander@datapath.co.uk X-Msg-Ref: server-13.tower-568.messagelabs.com!1641317339!44085!1 X-Originating-IP: [104.47.12.50] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.81.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1349 invoked from network); 4 Jan 2022 17:28:59 -0000 Received: from mail-db3eur04lp2050.outbound.protection.outlook.com (HELO EUR04-DB3-obe.outbound.protection.outlook.com) (104.47.12.50) by server-13.tower-568.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 4 Jan 2022 17:28:59 -0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VhGomo43H9mjPJUhowlfSknHuePhVV51NwTUr+LriGGPPEk95Hqu3xl/y6jzfJCxZ8sKSs7Cc6ye0ZTtsH/PhqH0UMsXD2oBxXyJrtyc2GbhrRSyxQCabGT5ccKieYv1kNtWvTZZsY+YMa5yzGqAFMHjFQv4Q7KQIZLrZPwqEDP5GXb0RyCMvgUepI2Brkr3Iya/xC+SGWloNGpgc8/U7MCTp/3aWQikKze9pqwUaHXgocljNuRfOQHJC9NHpjPYBYKI1segtqlrLCOe8QAuVk97gRXYxiw4tQt0t17NoNGkD68cSRi+ZQFpML1HzH+yLXpNIHFRwsPp9qisijLwkg== 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=kF/7HXyc+PnJn0VreLWFARXP+Drve0MMPybv3tFe0mU=; b=d71yc9TUqeaEO3UZrUM9xYR0xQ1lH4l0wI2p6L6HQHXRILTlw4Jk7we0DbQhCSM3TaKcfe4hYSaQRbCno/Fqk5NjPqJ6x55Gpp9NIBl5DFfneTAUQ0tkeQORGiU/s6x1fnf1DkMkeqaLC7Pf1SsQY3l2k8RkImc5pWTwhYgLVX7vDMgU8tuoUVrv0SHAlXAXrmupvDnsOFelb4MjG8yQ9zgyau/DloJlEgaGD4aYAvI3B/DoHIzSt/DyFiN8BMCq1QJldQS94Wjd4t33v28aJTidmuMUy2tYNH085WTwz4Nm3CFwKGFUfvze01jQGrmoSsArDnyJbcg79wUv6lJjNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=datapath.co.uk; dmarc=pass action=none header.from=datapath.co.uk; dkim=pass header.d=datapath.co.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datapathuk.onmicrosoft.com; s=selector2-datapathuk-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kF/7HXyc+PnJn0VreLWFARXP+Drve0MMPybv3tFe0mU=; b=tUay0JvYKs0aNFSTmOAsHvXSsZw0PLwPkzncnXe0CG1P7raIo1sLScxtRue0S7iu0ZDdaNlNSAng7tr+k+7cIxxCpChCTIrKhzTHFosDbr4uYP3lJaagY1fojIib+p8obIdInjSsmlihv9zMZa68MH7+GTTcydpNP9J+Dvlp5UI= Received: from DB6PR0902MB2070.eurprd09.prod.outlook.com (2603:10a6:6:d::23) by DB9PR09MB5065.eurprd09.prod.outlook.com (2603:10a6:10:2a5::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4844.15; Tue, 4 Jan 2022 17:28:58 +0000 Received: from DB6PR0902MB2070.eurprd09.prod.outlook.com ([fe80::584a:5f20:d022:2928]) by DB6PR0902MB2070.eurprd09.prod.outlook.com ([fe80::584a:5f20:d022:2928%5]) with mapi id 15.20.4844.016; Tue, 4 Jan 2022 17:28:58 +0000 From: John Alexander To: Elena Agostini , "NBU-Contact-Thomas Monjalon (EXTERNAL)" CC: "dev@dpdk.org" Subject: RE: [PATCH v2] gpudev: pin GPU memory Thread-Topic: [PATCH v2] gpudev: pin GPU memory Thread-Index: AQHYANAaoZxi/nZOrUOV3y+Qs7Y6GaxS0gqAgAARx4CAADrQ4A== Date: Tue, 4 Jan 2022 17:28:58 +0000 Message-ID: References: <20220104023408.13379-1-eagostini@nvidia.com> <20220104024100.14318-1-eagostini@nvidia.com> <12925392.uLZWGnKmhe@thomas> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6bf25a03-fd98-42b7-4830-08d9cfa7b0bd x-ms-traffictypediagnostic: DB9PR09MB5065:EE_ 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: t447kYCWj6trjsiSev1oygVm3OIRKY4geom7h3VIh/3+Lt4jy9aZnG9zwnZgZEg+j+HfZK9WlLkJcNXxeEt6U5Z0QxFtu4xwaSHO2YDz28NVQb3gLGC4ywVsLQwXCrKsWjJ1RsyCQmpBAYZw5F30cu3aUXn4e+G5f581rubgbzV9prbDu+vrQSKQwoPxX4yD4kyxCj66ZH8W9F9sNh1hf6VZ69qpE+4h6kbL/DKbmkQJaMxujpTS6U8DyvOplNNT5TVhqUlRFcPy1art0f8XLXvBHel1tl3Sa4s43GunGE/KvdY1EQCOzKJbtqwQ1QL6uEIqbpQrNAc7+PVVfcUbHrxl+jh+lZ4MJkjLTEcC/ePn+Ee3IU+Ofeovkfk7m4MlXTDnxmR0ksxEHjI+X5ngFeJIDkVfhraXhRy+nTjcQgmsfa4W9Qyt6XG1yaeE8DzTPiPMdhmw7DfK/acx3Scp6+0qV503AneI7+KSdZf153GU/o6811tHldFCnKxHlejG7WeqqFOcF4vvDbb6JgucUZuO4HxvtaCXazbdH4Rp+Og/QaZGFgQEpN8iUzH3qGYa3JrL4D36aZLyg+Gz1X2W+YpJVQ4S7otJXECX7S/h9jAgtJL6s+ibx3uEncA+C98S49z0D5T7naLB3ToYX8qiv7JtZghSYsPh6Oa5lhLa8NHTsJ4Z8lgRgJ9tf/R2kMXDDFYqSNwoo8uhK1pZbeGpww== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0902MB2070.eurprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(346002)(376002)(396003)(39850400004)(8936002)(110136005)(7696005)(53546011)(6506007)(4326008)(186003)(38070700005)(508600001)(33656002)(316002)(52536014)(55016003)(76116006)(9686003)(71200400001)(2906002)(66556008)(66946007)(5660300002)(38100700002)(122000001)(83380400001)(64756008)(66446008)(66476007)(8676002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?z9MBnl3fbUQZSYiwzZZGJLm04QVFCZPtzCIpDq3oQxoszbAPfqB/oNPL0D1p?= =?us-ascii?Q?+SchaTZ2bydwDakPyPhb3UpMBL1L7uHj6Btszw5UWt/mPjmq6KfUd+djFY7t?= =?us-ascii?Q?q5iOlNz6cHwiJq2MmexQs7cZGUmrRz0lftGk079u9XFmH5o54ZBBWJpP+H9f?= =?us-ascii?Q?9Y8QdP3on/oYHnX32wL/FAr668ErJsAVQQ6tXuUf/VOtWhYUDjWgdXVIZWon?= =?us-ascii?Q?6sd3T9URHGYj5Ta0Qwo8rRSdNeBL/eRSIzKlLD6X2guJRSlwF10pUz1fK623?= =?us-ascii?Q?bvpJCyU1rZgPdbbkaDQNGpyhMM9Z19mn5zHCkVdF0h8MddVGYODEzRcfiMFw?= =?us-ascii?Q?WSZDl4KuDj66dzVld5Lx6lh7b64lJLEr7AX/TaI/UJNJkz9SF7bf2elpVOnM?= =?us-ascii?Q?3w4NHppuC/nSB459wDdgy9c8ytRhT3ilQmTd28H5ibL0UW4WYSMp4cxy/YSz?= =?us-ascii?Q?y4qcWffNKVNYQqbW/9IPoioko08SOdMYStqD5UzqB/Nj4bUNUqxMM6+OXV+G?= =?us-ascii?Q?Tjxev+I52nlFIGRoxtQwFBf/+UzcMynJon5B6inlaAfwkJlLQS5YCQ14rCQi?= =?us-ascii?Q?/meLGmEOyLtjWSjuIBP4DSb5u3wRW2ZThzbY2jmLZ9PnVwbSlQXBD2BMq9q/?= =?us-ascii?Q?0C/KBk/xNhL/H7syZeXCXRr9Szl/MZqXt+wukoTUk8qDI9dyp2gAkCfw8LVC?= =?us-ascii?Q?KK3mlBNxzrNmmiHQOd1pMWASWSvw4MhEoadOCBvfjotO5JgKj4afSEWhr8VN?= =?us-ascii?Q?iLWA08uK5vYYoVThv9R1qJE+EbFCD3J5eudg4tNeJdFEi8cPUNo09TtvxJV3?= =?us-ascii?Q?4g2MdoEwIMQnggeS95pCiGkekqTsEfIggbf557GlvZ6YHWCU1g8lSdIMvIB5?= =?us-ascii?Q?aOd22Q4HzZJUdNu9+MPk1Y9vNKkgs/VF6cYlPUlSD1U4BWLCpEf9BnPktN9w?= =?us-ascii?Q?uuDYkeWf+ecvLdTi941iKiUHaPt2a3y3Sq+A3dHvDRD6rnhmP9o7IJ42ffle?= =?us-ascii?Q?cudlBCp2xvl78+8C3Y8Kx4VMLvC5upLpAO7bveZEeQEH7QLDqLpTGj3FqRqn?= =?us-ascii?Q?oHk0eHQ6f15VFy+G7sCpg6h9U/xG+Df16D1SdBAFH+qiYm4g6xBYCRO3qLTn?= =?us-ascii?Q?nyS881E8QgFNhZGvKFJyokrAeiaN4TAduat28Ge5o0WcAFmlb3zDuC4WTopM?= =?us-ascii?Q?1jwY08xpycDdx85GNj02dCT+Jgc8kS5J5xjbBNniQnX51VWpw8NctidnqmOj?= =?us-ascii?Q?OLtBEP4Zce/SqIyfBvO2HeIWFyv1ztwFocv459VrELyjDbjj7HPh28zW2Qyb?= =?us-ascii?Q?uZPfdp+4hC09x7cOqLPAtrwZS4X2ui8oPBLCJtku9NBV16SKhqjTyy4P47nn?= =?us-ascii?Q?2cH2BJzA9lUqfMuUuJ/4QgQTQyHcIDURG3u4olZLGPOM9GWlm6TRRHIl8xzY?= =?us-ascii?Q?Np/vKQzuyUALUuDcmdssVutQTpxDAYWvjdu/5Bo6F2seZxZAT8wMYvF82cxI?= =?us-ascii?Q?Qwy75AMTHoh4ACXjiw2n1Rd8Yg9w5IXSQCHQRxYjNsB04YyhoXwK5j7KHCjD?= =?us-ascii?Q?0+JK9SBRY/N1LjfQRPsSmVN9SDLb0aUlnXU0Ns81Owg4oS7w+vD5Ee3Jm98i?= =?us-ascii?Q?gVrHV6HMDQzE5a3zzFLH2n+NFlCWU9Czj3M13lYurRZ0X5wqA5orUMqIYg9Z?= =?us-ascii?Q?7Gr859Y5HUV9K2oc0l5AY0/5pz9PNAWLdJNeRftlFgrwSxZ5iFu6okX5KOm5?= =?us-ascii?Q?w9YdCltigg=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DB6PR0902MB2070F16AA72A6C1C331A2E09B44A9DB6PR0902MB2070_" MIME-Version: 1.0 X-OriginatorOrg: datapath.co.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB6PR0902MB2070.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6bf25a03-fd98-42b7-4830-08d9cfa7b0bd X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2022 17:28:58.0225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 102e0f24-523c-4823-a9ce-5a8ebc4e32a7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: trNNeqyTqKs6gsd3hdDCowGg+bkITDtHsZPQoO1uxfEpIj9oNtitMy5t8mpO/3dpNhWDnCvKerZlg/KNSgDcfWETE+bBYpvlcegh1BkmztM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR09MB5065 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 --_000_DB6PR0902MB2070F16AA72A6C1C331A2E09B44A9DB6PR0902MB2070_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What happens when the Nvidia GPU driver kernel callback occurs to invalidat= e the pinned GPU memory region? Doesn't the NIC need to cease all DMA tran= sfers to/from that region before the kernel callback can complete? From: Elena Agostini Sent: 04 January 2022 13:55 To: NBU-Contact-Thomas Monjalon (EXTERNAL) Cc: dev@dpdk.org Subject: Re: [PATCH v2] gpudev: pin GPU memory CAUTION: This email originated from outside of the organization. Do not cli= ck links or open attachments unless you recognize the sender and know the c= ontent is safe. > 04/01/2022 03:41, eagostini@nvidia.com: > > From: Elena Agostini = > > > > > Enable the possibility to make a GPU memory area accessible from > > the CPU. > > > > GPU memory has to be allocated via rte_gpu_mem_alloc(). > > > > This patch allows the gpudev library to pin, through the GPU driver, > > a chunk of GPU memory and to return a memory pointer usable > > by the CPU to access the GPU memory area. > > > > Signed-off-by: Elena Agostini > > [...] > > +/** > > + * @warning > > + * @b EXPERIMENTAL: this API may change without prior notice. > > + * > > + * Pin a chunk of GPU memory to make it accessible from the CPU > > You should define what means "pin" exactly. > Which properties should we expect? > Thanks for reviewing, this is the kind of discussion I wanted to have. Maybe "pin" is too GDRCopy specific oriented. Here I want to make a GPU memory buffer visible from the CPU. In case of NVIDIA, this means the GPU memory address has to be pinned (virtual addr= ess doesn't change) and dma-mapped. Maybe the name should be more like rte_gpu_mem_to_cpu() that's more explicative and generic. > > + * using the memory pointer returned by the function. > > Which function should return the pointer? > rte_gpu_mem_pin is returning an int. Oversight, will fix it. > > > > + * GPU memory has to be allocated via rte_gpu_mem_alloc(). > > Why pinning is not done by rte_gpu_mem_alloc()? > Should it be a flag? rte_gpu_mem_alloc() allocate virtual memory on the GPU that doesn't have to be necessarily shared (pinned) to make it visible from CPU. > > > + * > > + * @param dev_id > > + * Device ID requiring pinned memory. > > + * @param size > > + * Number of bytes to pin. > > + * Requesting 0 will do nothing. > > + * @param ptr > > + * Pointer to the GPU memory area to be pinned. > > + * NULL is a no-op accepted value. > > + > > + * @return > > + * A pointer to the pinned GPU memory usable by the CPU, otherwise N= ULL and rte_errno is set: > > + * - ENODEV if invalid dev_id > > + * - EINVAL if reserved flags > > Which reserved flags? > > > + * - ENOTSUP if operation not supported by the driver > > + * - E2BIG if size is higher than limit > > + * - ENOMEM if out of space > > Is out of space relevant for pinning? Yes, let me add it > > > + * - EPERM if driver error > > + */ > > +__rte_experimental > > +int rte_gpu_mem_pin(int16_t dev_id, size_t size, void *ptr); --_000_DB6PR0902MB2070F16AA72A6C1C331A2E09B44A9DB6PR0902MB2070_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What happens when the Nvidia GPU driver kernel callba= ck occurs to invalidate the pinned GPU memory region?  Doesn’t t= he NIC need to cease all DMA transfers to/from that region before the kernel callback can complete?

 

F= rom: Elena Agost= ini <eagostini@nvidia.com>
Sent: 04 January 2022 13:55
To: NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net&g= t;
Cc: dev@dpdk.org
Subject: Re: [PATCH v2] gpudev: pin GPU memory

 

<= span style=3D"color:#9C6500">CAUTION: This email originated from outside of the organization. Do not click link= s or open attachments unless you recognize the sender and know the content is safe.

> 04/01/2022 03:= 41, eagostini@nvidia.com:

> > From: Ele= na Agostini <eagostini@nvidia.co= m>

> >

> > Enable th= e possibility to make a GPU memory area accessible from

> > the CPU.<= o:p>

> >

> > GPU memor= y has to be allocated via rte_gpu_mem_alloc().

> >

> > This patc= h allows the gpudev library to pin, through the GPU driver,

> > a chunk o= f GPU memory and to return a memory pointer usable

> > by the CP= U to access the GPU memory area.

> >

> > Signed-of= f-by: Elena Agostini <eagostini@= nvidia.com>

> [...]

> > +/**=

> > + * @warn= ing

> > + * @b EX= PERIMENTAL: this API may change without prior notice.

> > + *<= /o:p>

> > + * Pin a= chunk of GPU memory to make it accessible from the CPU

>

> You should def= ine what means "pin" exactly.

> Which properti= es should we expect?

>

 

Thanks for reviewin= g, this is the kind of discussion I wanted to have.

Maybe "pin&quo= t; is too GDRCopy specific oriented.

Here I want to make= a GPU memory buffer visible from the CPU. In case

of NVIDIA, this mea= ns the GPU memory address has to be pinned (virtual address

doesn't change) and= dma-mapped.

 

Maybe the name shou= ld be more like rte_gpu_mem_to_cpu() that's more

explicative and gen= eric.

=  

 

> > + * using= the memory pointer returned by the function.

>

> Which function= should return the pointer?

> rte_gpu_mem_pi= n is returning an int.

 

Oversight, will fix= it.

 

>

>

> > + * GPU m= emory has to be allocated via rte_gpu_mem_alloc().

>

> Why pinning is= not done by rte_gpu_mem_alloc()?

> Should it be a= flag?

 

rte_gpu_mem_alloc()= allocate virtual memory on the GPU that doesn't have

to be necessarily s= hared (pinned) to make it visible from CPU.

 

>

> > + *<= /o:p>

> > + * @para= m dev_id

> > + * =   Device ID requiring pinned memory.

> > + * @para= m size

> > + * =   Number of bytes to pin.

> > + * =   Requesting 0 will do nothing.

> > + * @para= m ptr

> > + * =   Pointer to the GPU memory area to be pinned.

> > + * =   NULL is a no-op accepted value.

> > +

> > + * @retu= rn

> > + * =   A pointer to the pinned GPU memory usable by the CPU, otherwise NULL= and rte_errno is set:

> > + * =   - ENODEV if invalid dev_id

> > + * =   - EINVAL if reserved flags

>

> Which reserved= flags?

>

> > + * =   - ENOTSUP if operation not supported by the driver=

> > + * =   - E2BIG if size is higher than limit

> > + * =   - ENOMEM if out of space

>

> Is out of spac= e relevant for pinning?

 

Yes, let me add it<= o:p>

 

>

> > + * =   - EPERM if driver error

> > + */=

> > +__rte_ex= perimental

> > +int rte_= gpu_mem_pin(int16_t dev_id, size_t size, void *ptr);

--_000_DB6PR0902MB2070F16AA72A6C1C331A2E09B44A9DB6PR0902MB2070_--