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 6C1B1A034F; Mon, 11 Oct 2021 10:18:17 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5651B40E0F; Mon, 11 Oct 2021 10:18:17 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 49FE840142; Mon, 11 Oct 2021 10:18:16 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C98385C00DE; Mon, 11 Oct 2021 04:18:14 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 11 Oct 2021 04:18:14 -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=fm2; bh= e49MaUBdjmumjyKXg6LJeEzBEnFFFeCiRcAC7epXs+o=; b=K87iRa719ddupNeD M7pNLzKg7znSnH1pADC/CyykUXf7g4msAhVBr4EZAfw8mV6blRcPOIW7a2SpEYr4 qoSVo4WClGTxtZTwMtqkiX7P0EADW3uHbi0+/m92+Cqu8BelYGaWivyHCmHeqx6J kO/9PkHgOVgfeXcA4FCoyoWX+pXrznD3EZwinY9Nm82wv4wjH9g3zBPgIZ04jryO xP8BXxYQJHHVCi4eyFolby4giD2nHur6x3K4sm5f14GR+wCmrsXhQ0nYrGPmGXgp cpZHaBWesCVb5kIljI6vUNkaveT15Yi1zJTuaPj957+vNDnkIrGoHzqoUWZTgdeh Zn/WgQ== 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=fm1; bh=e49MaUBdjmumjyKXg6LJeEzBEnFFFeCiRcAC7epXs +o=; b=YrqKUukh1qIl0oTai/dQRkewPrKLcZwPvRoccXBhL1OYe0pGac2rjvSZr bMeMNi7+jJb/g946dYtsWpjPbLwdLKV+aOV5REAK0kfWBJg/FQ9ChIYLxVAZmrBE PUdjjWKZ8VRRV3s4DwKGkHwDujbr9OfFzmFH9ffOjoP0LXoN4+sBirWOVagSjg4Z Ov9JrL1CR61Q74+XfsYB+SzwrJNKanVzN9DesUFoTQzjBd61IWJOqmRjLoAU0GCW dCaqhkesKxuBsdcWwcah07gPFs/JyFR/dm8GhMGuGrEHIQ+P3JonsHLbqC0BvwLs 89A96igWTJTEPHNsp3n8TQ/RFBIpg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddthedguddvjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 11 Oct 2021 04:18:13 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: Elena Agostini , Ferruh Yigit , Honnappa Nagarahalli , dpdk-dev , techboard@dpdk.org Date: Mon, 11 Oct 2021 10:18:09 +0200 Message-ID: <2086339.rAQZMriH8I@thomas> In-Reply-To: References: <20210602203531.2288645-1-thomas@monjalon.net> <20211009015349.9694-1-eagostini@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 0/9] GPU library 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" 10/10/2021 12:16, Jerin Jacob: > On Fri, Oct 8, 2021 at 11:13 PM wrote: > > > > From: eagostini > > > > In heterogeneous computing system, processing is not only in the CPU. > > Some tasks can be delegated to devices working in parallel. > > > > The goal of this new library is to enhance the collaboration between > > DPDK, that's primarily a CPU framework, and GPU devices. > > > > When mixing network activity with task processing on a non-CPU device, > > there may be the need to put in communication the CPU with the device > > in order to manage the memory, synchronize operations, exchange info, etc.. > > > > This library provides a number of new features: > > - Interoperability with GPU-specific library with generic handlers > > - Possibility to allocate and free memory on the GPU > > - Possibility to allocate and free memory on the CPU but visible from the GPU > > - Communication functions to enhance the dialog between the CPU and the GPU > > In the RFC thread, There was one outstanding non technical issues on this, > > i.e > The above features are driver specific details. Does the DPDK > _application_ need to be aware of this? I don't see these features as driver-specific. > aka DPDK device class has a fixed personality and it has API to deal > with abstracting specific application specific > end user functionality like ethdev, cryptodev, eventdev irrespective > of underlying bus/device properties. The goal of the lib is to allow anyone to invent any feature which is not already available in DPDK. > Even similar semantics are required for DPU(Smart NIC) > communitication. I am planning to > send RFC in coming days to address the issue without the application > knowing the Bus/HW/Driver details. gpudev is not exposing bus/hw/driver details. I don't understand what you mean. > Irrespective of the RFC I am planning to send and since the new > library needs techboard approval, You may > request that the techboard decide approval for this library. Also, As > far as I remember a minimum a SW driver in > additional to HW driver to accept a new driver class. No, only one driver is required: "When introducing a new device API, at least one driver should implement it." Anyway, a SW driver doesn't make sense for gpudev.