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 8973CA034F; Tue, 8 Jun 2021 09:09:49 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 34B1A410E7; Tue, 8 Jun 2021 09:09:49 +0200 (CEST) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) by mails.dpdk.org (Postfix) with ESMTP id 8D13E4013F for ; Tue, 8 Jun 2021 09:09:47 +0200 (CEST) Received: by mail-il1-f178.google.com with SMTP id z1so18734645ils.0 for ; Tue, 08 Jun 2021 00:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y1bzT5ROhxfOnMJ3zCTKRrcxAZMELAINteB52uzxGOw=; b=Q15djjHCKog4qIri22XuFok6tVXPzLvt/1DKPu8+XtNaGCGRilA9L9NjDC7mfZqH35 w8hkbH5jfMMC3EgGnp9prPe7DYFdwjGZg3TiuBzD4feDhX+sWfU2pEQT7HWIJi8us6iO AT++uF26n3wqgjBONpG//hORU9uIPVx8n9OBk3Kut5vMbQefU8OW2xq8A018YfZFZQpY k2S+oSr2jgoqwE6dOyAGb6jTqmWlbTeqNeZ+K45YLE1e1nrRKfn7JnP30ppRBJmLRBpk 6sd3mCa7xeNA/KK+YA9SqcX98u6mKvrbcTD24dtEiMbAfz01l1DaABrLqKwgp0F9Ha3W IL7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y1bzT5ROhxfOnMJ3zCTKRrcxAZMELAINteB52uzxGOw=; b=lNCIvQ+jMwdAVqX2eLAaNPcR/2ji6bxUXNLFZovmt392IqxbnPLWXx1cLOysmZKheD OpGCqb1SyhZGDF2NYX4GVabm0HTmRIXrnl/kS5obuWNIum3a0RhyVnN31A5aAXkpuyYY jQE5z47BDNonCMywtynjkWpmTLMyMfdS4MeAv2EW/jX8/H0WzY0JGZVTA68MZZJwKEU+ lYxUkZan4Xlq8adn3mfzWUpiPuw7BGbkFNnM7ztcbHcJNt69MV7M4o+Tw/dxd1HZXDdn DM3dJANSEpFuenMaVcquU3s3Xvr3UBZ8OCBiPKToiNkS6F1Er0SsoDlbmg3wUhceyBJw 0SrA== X-Gm-Message-State: AOAM530Qp3JFgWIaFoIh0nIulFa92MR8c2JMm3JiLVEOzlvO6H3wA94f ll159zn4vTfbR1lzC+dIGr88BnWFERxV1lZbkDQ= X-Google-Smtp-Source: ABdhPJx1xqsEbN+OnX9kA5XWU04YyNAS5Z1q5C3LySuj9/LLxM0k6xiBWk/u7RUbS+AM0hD/4n4S7mkd47THIMdHU1s= X-Received: by 2002:a05:6e02:5d1:: with SMTP id l17mr18461396ils.162.1623136186857; Tue, 08 Jun 2021 00:09:46 -0700 (PDT) MIME-Version: 1.0 References: <20210602203531.2288645-1-thomas@monjalon.net> <2428387.JO1QuEOxcK@thomas> <2152098.qji4Z79139@thomas> In-Reply-To: <2152098.qji4Z79139@thomas> From: Jerin Jacob Date: Tue, 8 Jun 2021 12:39:30 +0530 Message-ID: To: Thomas Monjalon Cc: Honnappa Nagarahalli , Andrew Rybchenko , "Yigit, Ferruh" , dpdk-dev , Elena Agostini , David Marchand , nd , "Wang, Haiyue" Content-Type: text/plain; charset="UTF-8" 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" On Tue, Jun 8, 2021 at 12:05 PM 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 portal application will be using class device API. For example, when application needs to call rte_gpu_malloc() vs rte_malloc() ? Is it better the use of drivers specific functions used in "class device driver" not exposed? > 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). I would like to have a generic _application_ API if the application _needs_ to use it. The v1 nowhere close to any compute device description. It has a memory allocation API. It is the device attribute, not strictly tied to ONLY TO computing device. So at least, I am asking to have concrete proposal on "compute device" schematic rather than start with memory API and rubber stamp as new device adds anything in future. When we added any all the class devices to DPDK, Everyone had a complete view of it is function(at RFC of each subsystem had enough API to express the "basic" usage) and purpose from the _application_ PoV. I see that is missing here. > >