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 01DFBA0093; Tue, 4 Jan 2022 13:51:52 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 854A440040; Tue, 4 Jan 2022 13:51:52 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 4AA2C4003C for ; Tue, 4 Jan 2022 13:51:51 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E12A15C018F; Tue, 4 Jan 2022 07:51:49 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 04 Jan 2022 07:51:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= RChNmNR1UE8oDGgtQ/n7AYNt8SF/uukoKXmehKNWH4A=; b=Iy1wxPF8hzs3Q2Y8 HGCtXhTj73JVPI7s/IS9zCBJ1IxQRQQYILPLV6JLYMQOJPkUbXH52j8X+Jj4ot+4 nkAe3B5OIPffmwmgctKLgq4e6jqQHTZHIJKczaz0oH75qpU0Iwowa45ViuzFXdxK N+Hro4eHhSo5lY8lVqXBUMLdto/L/dMrloA2P6WV4zQvSSNX5ONIRJNmjDiMU9/S 3Lq0T71A0uA7uWYbL0g8aSm75zJ9CtycHT6Jsso5nAE7x9j6jQXwedt1OCroFzPQ lr6Hsp0V9uW71UXnKz3PHARKXJak/bxZqdUJsn/iXKU2axJyxbkzel3NySbmIyuj bKiI6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=RChNmNR1UE8oDGgtQ/n7AYNt8SF/uukoKXmehKNWH 4A=; b=AzXDssFXYEP816nVxfrima5zcpEhwq1cHJvKTasrqEbZQrCocbT/hZYIx iQP5rxXkIU1mX1p6jElvsLuUdJ6FoUWRWIrw0QAplWZx1Ln/TNG9At1y4r/9zVnA Gh9uBZlZgDMD62adojAhsnrqP1FYUPFA1m45UkOnLhvVYRNkxLP0J9hee9Z8sL9y F/c+Wq5BNqzsLMDqJezmOhVhVgSLoyFu8YRfb4WAbFDOZl1KgFrEah6GbgRH3ih6 mBDX21apPeMw/5G2LcWe0hXt0z1NpM8+uGDshNvSlzXRxtDgc+P1ikzpGxHjv0ua kN/zGFjj5haXhrx/Uf4Hs7MBjbzNg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudeffedggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 4 Jan 2022 07:51:49 -0500 (EST) From: Thomas Monjalon To: Elena Agostini Cc: dev@dpdk.org Subject: Re: [PATCH v2] gpudev: pin GPU memory Date: Tue, 04 Jan 2022 13:51:47 +0100 Message-ID: <12925392.uLZWGnKmhe@thomas> In-Reply-To: <20220104024100.14318-1-eagostini@nvidia.com> References: <20220104023408.13379-1-eagostini@nvidia.com> <20220104024100.14318-1-eagostini@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 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? > + * using the memory pointer returned by the function. Which function should return the pointer? rte_gpu_mem_pin is returning an int. > + * 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? > + * > + * @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 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 space relevant for pinning? > + * - EPERM if driver error > + */ > +__rte_experimental > +int rte_gpu_mem_pin(int16_t dev_id, size_t size, void *ptr);