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 6EED4A034F; Mon, 11 Oct 2021 11:12:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EE3A040E01; Mon, 11 Oct 2021 11:12:57 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id EF78540142; Mon, 11 Oct 2021 11:12:56 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9EDE45C00AC; Mon, 11 Oct 2021 05:12:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Mon, 11 Oct 2021 05:12:56 -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= JijSPGh6wjpk+zZv7DLGnmVy53dZQx2wrThjp1QVE+k=; b=PVrNsa3XxhDbRveQ ImP6C4KKJmKqoVMAkWBQa1+wHk8AoPH1BYD5McEjKf/mydN3Zl/Z3wGcfC32mPjf aOjYsOW+ci9IBTJ7PCUggO6hrVbpsjqUUTC7c7MAsYz4kjbsIS2gTSQi1nl52z2+ GtcaXeXEqTQIxPDG/Ec7htosTM+fs6ta9T3aOTnBoN+u8vqjkPpA96j/5k6zIMhm lJITjFixshccIh4vZr6xPR78jVrx4cvv+ZzcLZhEzwWPWcPtqW0jzEF8SBhzHfMQ bhNHn7mhJo+zwOHfZu+ZD6WpBRn4smSwdMkdHu5Gs40AnE5ZenpLpLN3Uv7DiuPb Hxl13g== 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=JijSPGh6wjpk+zZv7DLGnmVy53dZQx2wrThjp1QVE +k=; b=I/eiGGqQs2xEnNQamQn4Nx3PMJ+2gwDIrKDN2HwhkOzXDfVY9HMOGi5lL PbCkNcIiYakEAaKiA/PM30XfrZADlvHkbKvef0BJnYRYFkV1bP7fDWueaEWQWcx8 KYgCfFxcl4bnIoz4Hr012K87GYdUkcz36VJHpjEWM/yBd1h2HtITxyYX6e4cqq7q 9v4TyQCE3+9zSnlOvpGs8eTtmtips6eLTWanHRzjXURyZEaZO0Lljz5S/IoJ3q28 d4O24gMhQI8Jq/xq0SBxKr89r7GRZvcyNwbr1yv9wx90oLn3oXDfORM3dxIfTv+f HBHz/NN4Rv43/WH/JWKWSY5p5Aq8A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtiedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 11 Oct 2021 05:12:55 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: Elena Agostini , dpdk-dev , techboard@dpdk.org Date: Mon, 11 Oct 2021 11:12:52 +0200 Message-ID: <18783192.D4B0UDpyQ6@thomas> In-Reply-To: References: <20210602203531.2288645-1-thomas@monjalon.net> <2086339.rAQZMriH8I@thomas> 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" 11/10/2021 10:43, Jerin Jacob: > On Mon, Oct 11, 2021 at 1:48 PM Thomas Monjalon wrote: > > 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. > > That is the disconnect. I see this as more driver-specific details > which are not required to implement an "application" facing API. Indeed this is the disconnect. I already answered but it seems you don't accept the answer. First, this is not driver-specific. It is a low-level API. > For example, If we need to implement application facing" subsystems like bbdev, > If we make all this driver interface, you can still implement the > bbdev API as a driver without > exposing HW specific details like how devices communicate to CPU, how > memory is allocated etc > to "application". There are 2 things to understand here. First we want to allow the application using the GPU for needs which are not exposed by any other DPDK API. Second, if we want to implement another DPDK API like bbdev, then the GPU implementation would be exposed as a vdev in bbdev, using the HW GPU device being a PCI in gpudev. They are two different levels, got it? > > > 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. > > See above.