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 35351A0A0F; Fri, 4 Jun 2021 16:06:21 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B25B44068F; Fri, 4 Jun 2021 16:06:20 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 1734F40147 for ; Fri, 4 Jun 2021 16:06:19 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id BD0705C012E; Fri, 4 Jun 2021 10:06:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 04 Jun 2021 10:06:17 -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= IwQsL5wkUY8X3MMYC6pYOs4YWoCi2lYBkkfR4NCcucs=; b=KlXmlAL+zWuwry40 TCjydqDjs95dt75rhbeTErtd9pGanrEPYmTVXv8YLSTb9VtPVyjoAbsmzTVeF41p 5uCICYqgEvafN//SK1GJgZfdStYC7yNly988iP/XhB2McRfD5VfUlDSY/UL0z/CL RXCIslqpdSzi5qNEHOiODTeUzKqID9KjBogizvGhKrqOvik4HmdETSkCDAkWROag 4/DgdNZlrS71cVpRwcfJ42Vow4yUVitFRCOIHlVpGBY+oaBxq8FLZKN6Ql9+deZj fbwfPzBDyXA9HXCjVcXouf8jlgyEj/NYamMyQnlItc23rNuNCifP9MzYqsA9FNJX cNVwww== 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=IwQsL5wkUY8X3MMYC6pYOs4YWoCi2lYBkkfR4NCcu cs=; b=kN9jvn4dEDpf+RlwfkUpm+guK8YOvIHpau5mcCSbfSQWdONTPEdQr/cIQ s9iPstNvuyC+/KLlDnftI1/MDUQUnP+9xkrN8PcO0G5aI9jIK2+WEVrU2EXQ6OKI b8tlDpfrQr/txN3bRPqqsnPeu/G3MUsYDj437aBR5ApbNBWdT1Kf0gb9Hny31nQc /wH339QwEZg8iB1CkDqB3Wei5Q6FNmQZPzxUFf/xbiyvg0ZI8KZpqFIDKZsqFWP/ hi2yAFbwiuy6f1elPpgoAHa4V8YUYsNkrvUvDVSQLkWmc0INBiYIfEtT9Xt4OKh0 syfC5K0wlICznMt3tq9CP+4+7gzmg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtuddgjeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 4 Jun 2021 10:06:15 -0400 (EDT) From: Thomas Monjalon To: "Wang, Haiyue" Cc: dev@dpdk.org, Elena Agostini , andrew.rybchenko@oktetlabs.ru, ferruh.yigit@intel.com, jerinj@marvell.com Date: Fri, 04 Jun 2021 16:06:14 +0200 Message-ID: <1648109.dXcHqNedQ3@thomas> In-Reply-To: References: <20210602203531.2288645-1-thomas@monjalon.net> <1628314.htsJS64bL4@thomas> 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 15:25, Wang, Haiyue: > From: Thomas Monjalon > > 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? > > > > I didn't find the rte_gpu_free_visible definition, and the rte_gpu_free's > comment just says: deallocate a chunk of memory allocated with rte_gpu_malloc* > > Looks like the rte_gpu_free can handle this case ? This is the proposal, yes. > And from the definition "rte_gpu_free(uint16_t gpu_id, void *ptr)", the > free needs to check whether this memory belong to the GPU or not, so it > also can recognize the memory type, I think. Yes that's the idea behind having a single free function. We could have some metadata in front of the memory chunk. My question is to confirm whether it is a good design or not, and whether it should be driver specific or have a common struct in the lib. Opinions?