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 0B8B7A0C4B; Tue, 15 Jun 2021 20:54:50 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8394F4067A; Tue, 15 Jun 2021 20:54:50 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id B2FEF40140 for ; Tue, 15 Jun 2021 20:54:49 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id E30675C01F3; Tue, 15 Jun 2021 14:54:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 15 Jun 2021 14:54:47 -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= A1WAEcfW/ZEJkz2eRHkffV83EJYuUeS6kB5zVzUHi9Q=; b=5aDFP/caW3WfVV9K wiiauWDcUz2kYXngsRdYC/Zg7j9hk7xLplVFZbhdxc4E15YO1YLl4dDnQNr6onMi Cct4gLjzqaX1U+CyaYz9b01ZyPWcpHOa5rc5pi54yH5Q4uAh5gA8pObV6BewtQHr xPfjdUQu9fcu7fMimiFT+IaOJq5pAVYl+EmBBNcbc6Bxlb2La0hRUjuIpbGG3C68 fM56yJ6T54tcTWL0DIqg1fcL8ziKolKW1hrHfN7Zx15w2VhdhtAhrhwy+Ekzl4zs uB1DQ2efzxDTs9ohcjwj2JpFyMBzmzqw1ajYv9jHAqK23Q1drUdmwbEZaJ8q9rBM iSBNUw== 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=A1WAEcfW/ZEJkz2eRHkffV83EJYuUeS6kB5zVzUHi 9Q=; b=FMts0MPA7OAOtMNpIAYlaXjec2ZJ/VKLjGAGTuNYl3pGSFNZnQzXktLKg xp4qrEnY0JixVufwFlp1UKjAtT541PHfdGxHKzyBRR5AmKfymEga65RgsDi+bZeS 1HWK+e8e5VP5TNRZLYLv5MPtMAjHtFfPTj9JTMxyceOTwoGHvAuW4aSJt+3IhEq0 xAM+JchFoOuqsUuW5FJfCB6diRQh5xycuGx8KTnlGsO4Cp2Ee201Nwr3iws7V9dR 7NqGPPoHCG6HeSFQfgdDXNoSIFAJ4el3OKy93paUrB3vI/O8CJl1BDuSFkfDmzOi 33rFVJv+SyBp/6UcSZ2M4vHGLXBPw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedvjedgudefudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Jun 2021 14:54:46 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob , Ferruh Yigit Cc: Honnappa Nagarahalli , Andrew Rybchenko , dpdk-dev , Elena Agostini , David Marchand , nd , "Wang, Haiyue" Date: Tue, 15 Jun 2021 20:54:44 +0200 Message-ID: <1698995.VmdQvlHQHK@thomas> In-Reply-To: <874dd14b-88a8-c94b-16d7-223bcc31c56c@intel.com> References: <20210602203531.2288645-1-thomas@monjalon.net> <2152098.qji4Z79139@thomas> <874dd14b-88a8-c94b-16d7-223bcc31c56c@intel.com> 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" 15/06/2021 20:24, Ferruh Yigit: > On 6/8/2021 7:34 AM, Thomas Monjalon wrote: > > 08/06/2021 06:10, Jerin Jacob: > >> On Mon, Jun 7, 2021 at 10:17 PM Thomas Monjalon wrote: > >>> > >>> 07/06/2021 15:54, Jerin Jacob: > >>>> On Mon, Jun 7, 2021 at 4:13 PM Thomas Monjalon wrote: > >>>>> 07/06/2021 09:20, Wang, Haiyue: > >>>>>> From: Honnappa Nagarahalli > >>>>>>> If we keep CXL in mind, I would imagine that in the future the devices on PCIe could have their own > >>>>>>> local memory. May be some of the APIs could use generic names. For ex: instead of calling it as > >>>>>>> "rte_gpu_malloc" may be we could call it as "rte_dev_malloc". This way any future device which hosts > >>>>>>> its own memory that need to be managed by the application, can use these APIs. > >>>>>>> > >>>>>> > >>>>>> "rte_dev_malloc" sounds a good name, > >>>>> > >>>>> Yes I like the idea. > >>>>> 2 concerns: > >>>>> > >>>>> 1/ Device memory allocation requires a device handle. > >>>>> So far we avoided exposing rte_device to the application. > >>>>> How should we get a device handle from a DPDK application? > >>>> > >>>> Each device behaves differently at this level. In the view of the > >>>> generic application, the architecture should like > >>>> > >>>> < Use DPDK subsystem as rte_ethdev, rte_bbdev etc for SPECIFIC function > > >>>> ^ > >>>> | > >>>> < DPDK driver> > >>>> ^ > >>>> | > >>>> > >>> > >>> I think the formatting went wrong above. > >>> > >>> I would add more to the block diagram: > >>> > >>> class device API - computing device API > >>> | | | > >>> class device driver - computing device driver > >>> | | > >>> EAL device with memory callback > >>> > >>> The idea above is that the class device driver can use services > >>> of the new computing device library. > >> > >> Yes. The question is, do we need any public DPDK _application_ APIs for that? > > > > To have something generic! > > > >> If it is public API then the scope is much bigger than that as the application > >> can use it directly and it makes it non portable. > > > > It is a non-sense. If we make an API, it will be better portable. > > The only part which is non-portable is the program on the device > > which may be different per computing device. > > The synchronization with the DPDK application should be portable > > if we define some good API. > > > >> if the scope is only, the class driver consumption then the existing > >> "bus" _kind of_ > >> abstraction/API makes sense to me. > >> > >> Where it abstracts, > >> -FW download of device > >> -Memory management of device > >> -Opaque way to enq/deque jobs to the device. > >> > >> And above should be consumed by "class driver" not "application". > >> > >> If the application doing do that, we are in rte_raw device territory. > > > > I'm sorry I don't understand what you make such assertion. > > It seems you don't want generic API (which is the purpose of DPDK). > > > > The FW/kernel/"computing tasks" in the co-processor can be doing anything, as it > has been in FPGA/rawdev. > > If there is no defined input & output of that computing task, an application > developed using it will be specific to that computing task, this is not portable > and feels like how rawdev works. > > It is possible to have a generic API for control, to start the task and get > completion notification, but not having common input/output interface with > computing task still has same problem I think. > > If the application is strictly depends to what computing task does, why not > extending rawdev to have the control APIs? Instead of new library. > And as you already said for memory, generic APIs can be used with additional > flags and using rawdev handler. > > Or another option can be defining computing task a little more, have a common > interface, like mbuf, and add some capabilities/flags to let application know > more about computing task and give decision based on it, is this the intention? I think we'll propose a thin layer to allow device memory management with generic API in EAL and mbuf. The task should be defined and controlled by the application, and there is not much DPDK can do generically. Stay tuned, and thanks for all the feedbacks.