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 A933BA034F; Mon, 7 Jun 2021 12:30:00 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 582AA4067E; Mon, 7 Jun 2021 12:29:59 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 5C39B40147 for ; Mon, 7 Jun 2021 12:29:57 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B49F05C0178; Mon, 7 Jun 2021 06:29:55 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 07 Jun 2021 06:29:55 -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= nHSPJ0hiqX3HZ7zgPMG9HOkQYWMgAnkSlpWylaBSA5c=; b=nMuzdJVOyu0rbvbm hTePM+JcJMFxOVsuZZ3qyzXomcofHtw/bB80yqdIsH2LMyusx793Vi/iJo1+utZN 70xzZn+xdH6Zf8zU3cFauLc3q7DXDbbeDNHY7X44a1DI5gVLvkOfk0ALkTOfjvR3 pewjEChHZce5NuNbN8XQzPdPGTVEWnW2O8eyg3wU9TFLT6mnnxE3eCUY+teCVdnj qdidH9kDN1jjmeVSXufno1eG8gZBSaNE/UqiX/9piEQAMcbih2lUVw2R8OOxd8tb EtTkOzxOzkbAfJQ21pYTak+d/Eqw6eXVyCW6FgN0DXSqLg1fMF95TuvkfC1lxXIt 7urB6Q== 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=nHSPJ0hiqX3HZ7zgPMG9HOkQYWMgAnkSlpWylaBSA 5c=; b=cgTW0lracOOAZDKM9JQ6KrAFxsRmrFVvmBCYuN54fXED5v8EN3uYdx0FN IMSeGVgJXf/x60mPOHt/xumJogsBKL97U+drNDSfqJCxmmFvfkUMeZXV3b2y2wam 45zQM6iowoCyjVSRZOmBEpa4VaO1Zx9osG7vGHZUKGTVqQ3Wcg9tBx25g6PhPvpu G8gIPGScsi5yAsKqd5lPb5svh3huVPNMaE5xKbjczMXAdLPveYa8w98fr0G8SeM1 T4LWivxZ0f8hQPeWI8Hqq9hGqxjzsWzI8aQf4tzq1lxEa/j5w+PQh3MqjefY05dG qoofBXUCYv725vgsMSMmMA9oiubhQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtjedgvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepiefhjefhkeetuddtvedufeeifeetheethfeviedufeelvdegvdel hfevtedvieevnecuffhomhgrihhnpeifihhkihhpvgguihgrrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhn jhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 7 Jun 2021 06:29:53 -0400 (EDT) From: Thomas Monjalon To: Honnappa Nagarahalli Cc: dev@dpdk.org, "Wang, Haiyue" , Andrew Rybchenko , "Yigit, Ferruh" , dpdk-dev , Elena Agostini , David Marchand , nd , Jerin Jacob Date: Mon, 07 Jun 2021 12:29:50 +0200 Message-ID: <2472665.VJLooJfWnV@thomas> In-Reply-To: References: <20210602203531.2288645-1-thomas@monjalon.net> 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" 06/06/2021 07:28, Jerin Jacob: > On Sun, Jun 6, 2021 at 6:44 AM Honnappa Nagarahalli > > This patch does not provide the big picture view of what the processing looks like using GPU. It would be good to explain that. > > For ex: > > 1) Will the notion of GPU hidden from the application? i.e. is the application allowed to launch kernels? > > 1a) Will DPDK provide abstract APIs to launch kernels? > > This would require us to have the notion of GPU in DPDK and the application would depend on the availability of GPU in the system. Not sure "kernels" is a well known word in this context. I propose talking about computing tasks. The DPDK application running on the CPU must be synchronized with the tasks running on devices, so yes we need a way to decide what to launch and when from the DPDK application. > > 2) Is launching kernels hidden? i.e. the application still calls DPDK abstract APIs (such as encryption/decryption APIs) without knowing that the encryption/decryption is happening on GPU. > > This does not require us to have a notion of GPU in DPDK at the API level > > I will leave this to Thomas. The general need is to allow running any kind of processing on devices. Some processing may be very specific, others could fit in the existing class API like crypto and regex. I think implementing such specific class drivers based on tasks dynamically loaded on the device may be done as a second step. Thank you for the questions, it helps defining the big picture for the next revision of the patch. > > 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. > > That is a good thought. it is possible to hook the download firmware, > memory management, Job management(as messages to/from device) to > rte_device itself. > I think, one needs to consider, how to integrate with the existing > DPDK subsystem, for example: If one decided to implement bbdev or > regexdev with such computing device, > Need to consider, Is it better to have bbdev driver has depended > gpudev or rte_device has this callback and use with bbdev driver. Absolutely. If a specialized driver class fits with a workload, it is best handled with a driver in its specific class. > > > > > Yes baseband processing is one possible usage of GPU with DPDK. > > > > > We could also imagine some security analysis, or any machine learning... > > > > > > > > > > > I can think of "coprocessor-dev" as one of the name. > > > > > > > > > > "coprocessor" looks too long as prefix of the functions. > > > > > > Yes. Libray name can be lengthy, but API prefix should be 3 letters kind short > > > form will be required. > > > > > > > > > > > > > > > > > We do have similar machine learning co-processors(for compute) if > > > > > > we can keep a generic name and it is for the above functions we > > > > > > may use this subsystem as well in the future. > > > > > > > > > > > > > Accelerator, 'acce_dev' ? ;-) > > > > > > It may get confused with HW accelerators. > > > > > > > > > Some of the options I can think of. Sorting in my preference. > > > > > > library name, API prefix > > > 1) libhpc-dev, rte_hpc_ (hpc-> Heterogeneous processor compute) > > > 2) libhc-dev, rte_hc_ > > > (https://en.wikipedia.org/wiki/Heterogeneous_computing see: Example > > > hardware) > > > 3) libpu-dev, rte_pu_ (pu -> processing unit) > > > 4) libhp-dev, rte_hp_ (hp->heterogeneous processor) > > > 5) libcoprocessor-dev, rte_cps_ ? > > > 6) libcompute-dev, rte_cpt_ ? > > > 7) libgpu-dev, rte_gpu_ > > > > These seem to assume that the application can launch its own workload on the device? Does DPDK need to provide abstract APIs for launching work on a device? That's the difficult part. We should not try to re-invent CUDA or OpenCL. I think this part should not be in DPDK. We only need to synchronize with dynamic nature of the device workload. We will be more specific in the v2.