From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2E70BC47082 for ; Tue, 8 Jun 2021 06:35:06 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 4815E60C40 for ; Tue, 8 Jun 2021 06:35:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4815E60C40 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=monjalon.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7D709410E7; Tue, 8 Jun 2021 08:35:04 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 7B1CC4013F for ; Tue, 8 Jun 2021 08:35:02 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C1FED5C012E; Tue, 8 Jun 2021 02:35:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 08 Jun 2021 02:35:01 -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= yhSCoq/pO5krUCWOJIZaTpEITNtaQ798oe7lErpvH7U=; b=xwKJXiC6mV+ThKQE yme7C7FmAw2roSR2jKmBIgHJAtM0v56pIn7JYCymLxBMfhdvBFR3oHGKePX709wT z1mDRZpgQDGYBpxHpwaFLX3uNItJTiWdH/LsrqkBtHsc/BT3qcISRwSq7EgNqYs/ 84DanzNErTwxTZ4heDAD97m5tESdgPoyuQcg2u+wubwIzhnnaAMYBF5Ghg79UBF+ XX4WGii0eCnIZ3Qtt0So2rLiSpOUbeGhv44Y6it9vBxVh1t0npxjy2QGPQcHF91Y rtPuN6p0yN5yZSQPR1qGAtGvFJSIDV/9L86nzJgXHj/k/8xTGU26oX5/vTlOrZzh msVxbw== 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=yhSCoq/pO5krUCWOJIZaTpEITNtaQ798oe7lErpvH 7U=; b=S2ChP6th+JY5Y9FBMEHT1mMDEsiKnl4V+El94PBDi55HbD7S5ZSfqKP2+ 4lKkSl1Si6SBWh+KDXv66LXcPBuRm/YRyml57MkCn3LmM5jD/cT7fuFPnGsn7lyY zqwhrXUi0kfqMg0BosMIBZJ2Guu1helh0mIHY2TZvfeTblv44+81EO+55aFmNxVB Apwoy8xDJUce6FDZ72aSbG3nc0ALyPykdH9AwIzD67zmQlbJJO3pfwX1DtCaNmIq WgjGJT6Jey5e2tDq/OigROqDF4Goq6OiVpFUvJ8nAKAjeGpZGrQSPGxn8cCh7a1p iYLHwEzknaehuuBjVPLH08WBs1nhg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtkedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 8 Jun 2021 02:35:00 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: Honnappa Nagarahalli , Andrew Rybchenko , "Yigit, Ferruh" , dpdk-dev , Elena Agostini , David Marchand , nd , "Wang, Haiyue" Date: Tue, 08 Jun 2021 08:34:57 +0200 Message-ID: <2152098.qji4Z79139@thomas> In-Reply-To: References: <20210602203531.2288645-1-thomas@monjalon.net> <2428387.JO1QuEOxcK@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" 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).