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 95264A0A0F; Fri, 4 Jun 2021 14:46:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2021E4068F; Fri, 4 Jun 2021 14:46:45 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 8AF1840147 for ; Fri, 4 Jun 2021 14:46:43 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 35FBC5C012B; Fri, 4 Jun 2021 08:46:43 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 04 Jun 2021 08:46:43 -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= 9unkqAy8clS6e9ho9puJSgCSsO9CQjIAg8iqXoZDV6A=; b=EYx2wscCm/vPbNlr a1LJLBcLgiiLjpdmqoTQnDA/A8O5uUmYH5knIsQG5KRL2g0RdmJk1ycrQgpJdLKL NVnPD3luJ3Rw2BIlTxc5K9teWxTtdHRtLPdud5IDmU2dGDBf9jY6CGjtj7yxVh4I b3jOzACCXmMussJ4pMiSUQGYpd0DeI7A9/R9mzGBxt87y3ZgteKG/q77ieIUimMh qk8Nry2dNbnaI94zJECs7nZD8YYOWEz7kzdJBN0KM4/AC55DMd9cAztMpHrGTc34 TpWhxXYH2dnrNb6S5//QdRgq7TIZP47TRUcULAcCwTrqMb9cn4T2kfg+fU9dDtXa /tUFew== 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=9unkqAy8clS6e9ho9puJSgCSsO9CQjIAg8iqXoZDV 6A=; b=YsnLAuS4Qxpgh5vASeBDQnpSlrVNOFdLS6emv5KsPFWhDl0768prLF7YY Y/hLG7MrwKsPE8SIGSVf5Tf6+FPX/KmcLAsLmNCV/sTJZ1QYnVtF7/YAalW2I5C2 oVPRwxestc/fELIynD00Hnt2tT5RxW8/7w/6jedRDWJE7Aiit7RrmzqclIvazTz6 Rgr52kYzI07PAgWx2p8JCOU47IaijKZzCW5wNpmk+NmSX0HtOGI9nGybqGghTdpX ybC6qvdRfJyroYbNc6OhuXAq9RD5Yg8w7FVRTMNVi/5n/4qPlFajmWAKqxUaYdUo 3H4MUuwEJXOROEpcHjz01gvlyay/w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtuddgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 4 Jun 2021 08:46:41 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: Ferruh Yigit , dpdk-dev , Elena Agostini , david.marchand@redhat.com Date: Fri, 04 Jun 2021 14:46:38 +0200 Message-ID: <1817476.i3Lo7XacKO@thomas> In-Reply-To: References: <20210602203531.2288645-1-thomas@monjalon.net> <2043513.c5GKn8Mpaa@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 13:09, Jerin Jacob: > On Fri, Jun 4, 2021 at 3:58 PM Thomas Monjalon wrote: > > 03/06/2021 11:33, Ferruh Yigit: > > > On 6/3/2021 8:47 AM, Jerin Jacob wrote: > > > > On Thu, Jun 3, 2021 at 2:05 AM Thomas Monjalon wrote: > > > >> + [gpudev] (@ref rte_gpudev.h), > > > > > > > > Since this device does not have a queue etc? Shouldn't make it a > > > > library like mempool with vendor-defined ops? > > > > > > +1 > > > > > > Current RFC announces additional memory allocation capabilities, which can suits > > > better as extension to existing memory related library instead of a new device > > > abstraction library. > > > > It is not replacing mempool. > > It is more at the same level as EAL memory management: > > allocate simple buffer, but with the exception it is done > > on a specific device, so it requires a device ID. > > > > The other reason it needs to be a full library is that > > it will start a workload on the GPU and get completion notification > > so we can integrate the GPU workload in a packet processing pipeline. > > I might have confused you. My intention is not to make to fit under mempool API. > > I agree that we need a separate library for this. My objection is only > to not call libgpudev and > call it libgpu. And have APIs with rte_gpu_ instead of rte_gpu_dev as > it not like existing "device libraries" in DPDK and > it like other "libraries" in DPDK. I think we should define a queue of processing actions, so it looks like other device libraries. And anyway I think a library managing a device class, and having some device drivers deserves the name of device library. I would like to read more opinions.