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 55578A0A0F; Fri, 4 Jun 2021 14:43:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CD0554068F; Fri, 4 Jun 2021 14:43:55 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 1485E40147 for ; Fri, 4 Jun 2021 14:43:54 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 59E235C011D; Fri, 4 Jun 2021 08:43:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 04 Jun 2021 08:43:53 -0400 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=fm1; bh= 43j1uAu5Bg5YLoCXcAVUR51Qta1UNDQuSCgLPi9CRqo=; b=YdwTvhmiVmwR6Q+j H/4u9chHLZhgA06HXevTHgH6rA2CbGvD8imfueOezjx7e7zu3f+wbGIoIge9m9R8 ctoLyZ3XipLK98e3RJJSdjOac7sexz5ooyJmBiuepQnlk0eETLKwj8pDviJQBQF+ nq7AvhPyc/mr2wen7Yh4W/hQ8wOMcrDODm3vAdeOOrKcfyo2OU11WQ9DcK+jaTE8 yhUbX4wIjxAtWlCurQ7yVSWWsFF4vCYe8N63H8XeYTartlTuXnAdE2PfduitUYVM ECMgVw1WsDcXlaGe1xCqZvxI9ZRQYQmSjZTvLvYI7kpYwzCMZZt1/DBpEle4jANJ zbFTdA== 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=fm3; bh=43j1uAu5Bg5YLoCXcAVUR51Qta1UNDQuSCgLPi9CR qo=; b=weyN2WLD1NBq7kGUeVcU4C0FVzT7IRbZKPWMqgBKpTEsx2pCncAPQZjaQ ZRvbL3ZPfkdP1pwNbC2iEXwzslcD1ur7aFHXjxSk5QADNsQZlj0CGAYCcLFYP21V kjRRnf1MzqfHLhod9dnrJHCv8JDG8pOVtM+e3so9kvk+gI9mNDODeF3KVDO05Cim ilszFxbfaCmumWsbwpGqTsGFWSNn3MzJT4r+fwKitGnNQmjboGJXZfnGcrZBZrY1 tpbVd/0URTkB9V5xvCbUt1y3kNA79LPOzpeTUivzze7x0Y3huGJsuPs545T4i7TZ uo2VTGxIoYYMDyCBkOCleW7GAlGuA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtuddgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 4 Jun 2021 08:43:51 -0400 (EDT) From: Thomas Monjalon To: "Wang, Haiyue" Cc: "dev@dpdk.org" , Elena Agostini Date: Fri, 04 Jun 2021 14:43:50 +0200 Message-ID: <1628314.htsJS64bL4@thomas> In-Reply-To: References: <20210602203531.2288645-1-thomas@monjalon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] gpudev: introduce memory API 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" 04/06/2021 13:07, Wang, Haiyue: > > From: Elena Agostini > > +typedef int (*gpu_malloc_t)(struct rte_gpu_dev *dev, size_t size, void **ptr); > > +typedef int (*gpu_free_t)(struct rte_gpu_dev *dev, void *ptr); > > + [...] > > + /* FUNCTION: Allocate memory on the GPU. */ > > + gpu_malloc_t gpu_malloc; > > + /* FUNCTION: Allocate memory on the CPU visible from the GPU. */ > > + gpu_malloc_t gpu_malloc_visible; > > + /* FUNCTION: Free allocated memory on the GPU. */ > > + gpu_free_t gpu_free; > > > I'm wondering that we can define the malloc type as: > > typedef int (*gpu_malloc_t)(struct rte_gpu_dev *dev, size_t size, void **ptr, > unsigned int flags) > > #define RTE_GPU_MALLOC_F_CPU_VISIBLE 0x01u --> gpu_malloc_visible > > Then only one malloc function member is needed, paired with 'gpu_free'. [...] > > +int rte_gpu_malloc(uint16_t gpu_id, size_t size, void **ptr); [...] > > +int rte_gpu_malloc_visible(uint16_t gpu_id, size_t size, void **ptr); > > Then 'rte_gpu_malloc_visible' is no needed, and the new call is: > > rte_gpu_malloc(uint16_t gpu_id, size_t size, void **ptr, RTE_GPU_MALLOC_F_CPU_VISIBLE). > > Also, we can define more flags for feature extension. ;-) Yes it is a good idea. Another question is about the function rte_gpu_free(). How do we recognize that a memory chunk is from the CPU and GPU visible, or just from GPU?