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 08176A0A0A; Thu, 3 Jun 2021 12:30:06 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7DAC5410E2; Thu, 3 Jun 2021 12:30:06 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 9A9E540DF6 for ; Thu, 3 Jun 2021 12:30:04 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DF82D5C01BD; Thu, 3 Jun 2021 06:30:03 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 03 Jun 2021 06:30:03 -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= peqZpkWFIl26h7m1QX9gyra085w/DsHU+6O/ZUjnJng=; b=FSWNpfFLOQ8f9YbO gDS+42TKFO15lpl7EtPXJqr4lwn1RFnfeqm8XOH7H/qMQBRoqmrUYRwhN1K+PZUS OODz7A0IIKmBpmmVTZ5UT1r+Qqi8FR5hy4kaXl211fxtPNdto6DaAlx4eiHdIh5D IFcK+rpRgus2rUFKgvbr43uVhpLtIgh81iOubqPbwiht3aPdFLBLWwwlcs0CYTnH ElH1yZK0w6vJw029VBWRr+/gKPwLNU2Hq0iXRnPYJyeIPdilS6V3GLunPf3VLWff 0zEr0rHg+mRzm1IeQKeqDRK/imXlQvjxx2b5VNndO2sQ9I76Db4e2yYBmxPZZqLP XKXCrQ== 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=peqZpkWFIl26h7m1QX9gyra085w/DsHU+6O/ZUjnJ ng=; b=shq5EmIICslEnrXB91cwLffAk8dTgOB2lHp52AuogmPWARo1jWQ3y7NFs TT6YmEfBGFR3MBtDgJcpd8b3JbXXT2wPIkKHdJT8E/XwF3XBMQ7BDIFe0IO5cSPB nbBysnLD4BVPKKKUNGwbAzMyUGPteT/yI9hYDF7TrhMmdCsJa2bjRIYRicxawAE7 07WYgUVHa/rnJrJFXH2JeRU+7m2Mhj+Y05ANySgwB95SP9nXfPaoH0DhFe9bCUfq EcupevP6RhLNtI+/8l6yJqVV8UiDCRe8AuvJvBcW75hq/yAoaijzD7o/iTkG9fXv HEF8oh7b/ZJLzKg8NORPIGooSWJwg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdelledgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhn rdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 3 Jun 2021 06:30:02 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: dpdk-dev , Elena Agostini Date: Thu, 03 Jun 2021 12:30:01 +0200 Message-ID: <7088348.icZg66Z9Yi@thomas> In-Reply-To: References: <20210602203531.2288645-1-thomas@monjalon.net> <2514191.Ay6nQiMiuT@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" 03/06/2021 12:04, Jerin Jacob: > On Thu, Jun 3, 2021 at 3:06 PM Thomas Monjalon wrote: > > > > 03/06/2021 11:20, Jerin Jacob: > > > On Thu, Jun 3, 2021 at 2:23 PM Thomas Monjalon wrote: > > > > > > > > 03/06/2021 10:47, Jerin Jacob: > > > > > On Thu, Jun 3, 2021 at 2:13 PM Thomas Monjalon wrote: > > > > > > > > > > > > 03/06/2021 10:41, Jerin Jacob: > > > > > > > On Thu, Jun 3, 2021 at 1:58 PM Thomas Monjalon wrote: > > > > > > > > > > > > > > > > 03/06/2021 09:47, Jerin Jacob: > > > > > > > > > On Thu, Jun 3, 2021 at 2:05 AM Thomas Monjalon wrote: > > > > > > > > > > --- a/doc/api/doxy-api-index.md > > > > > > > > > > +++ b/doc/api/doxy-api-index.md > > > > > > > > > > @@ -21,6 +21,7 @@ The public API headers are grouped by topics: > > > > > > > > > > [compressdev] (@ref rte_compressdev.h), > > > > > > > > > > [compress] (@ref rte_comp.h), > > > > > > > > > > [regexdev] (@ref rte_regexdev.h), > > > > > > > > > > + [gpudev] (@ref rte_gpudev.h), > > > > > > > > > > > > > > > > > > Since this device does not have a queue etc? Shouldn't make it a > > > > > > > > > library like mempool with vendor-defined ops? > > > > > > > > > Any specific reason for making it a device? The reason why I am asking > > > > > > > > > this is, as other DPDK devices as symmetry in queue(s), configure, > > > > > > > > > start, stop operation etc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > + > > > > > > > > > > +struct rte_gpu_dev { > > > > > > > > > > + /* Backing device. */ > > > > > > > > > > + struct rte_device *device; > > > > > > > > > > > > > > > > > > See above? > > > > > > > > > > > > > > > > There is a PCI device probed. > > > > > > > > I don't understand why it would not be represented as a device. > > > > > > > > > > > > > > All other DPDK device has symmetry in structures like queue and > > > > > > > symmetry in operation like it has configure, start, stop etc. > > > > > > > This one seems more like mempool to me all we want set of > > > > > > > vendor-defined ops. So any justification on > > > > > > > make it a device ? why not like mempool library? > > > > > > > (driver/mempool/octeontx2 Mempool HW is also PCI device, but > > > > > > > we don't take device path for mempool. So I would like to understand > > > > > > > any technical reason for making it a device). > > > > > > > > > > > > I don't understand what you mean by "symmetry". > > > > > > > > > > The common attributes. or similarity > > > > > > > > The common attributes of a device are: > > > > - driver > > > > - bus > > > > - devargs > > > > We have these attributes for a GPU. > > > > > > Yes. Those are attributes of rte_device. That does not mean and > > > library can not use rte_device.(mempool library driver is using > > > rte_device which is backed by PCI) > > > In terms of similarity, all other device libraries(not devices) have > > > queue, enqueue() and dequeue() kind of scheme > > > in ethdev, cryptodev, compressdev, eventdev, bbdev, rawdev. regexdev. > > > i.e existing DPDK device libraries, > > > This one des not have have that, So question why to call it libgpudev vs libgpu. > > See below[1] > > > > > > > The functions you have are memory allocation etc. That's more of a > > > library candidate. > > > > > > > About configure/start/stop usual functions, > > > > I think we'll have something similar in the second step > > > > > > Do you think or it will be there?. I think, it is import decision. > > > > That's an important discussion we need to have. > > We are preparing a proposal. > > Ack. > > > > > > The device needs have a queue kind of structure > > > and it is mapping to core to have a notion of configure. queue_setup, > > > start and stop etc > > > > Why is it a requirement to call it a device API? > > Then we need to define what needs to call as device library vs library and how? > Why mempool is not called a device library vs library? My view is simple: if it has drivers, it is a device API, except bus and mempool libs. About mempool, it started as a standard lib and got extended for HW support. > and why all > other device library has a common structure like queues and > it binding core etc. I tried to explain above the similar attributes > for dpdk device libraries[1] which I think, it a requirement so > that the end user will have familiarity with device libraries rather > than each one has separate General guidelines and principles. > > I think, it is more TB discussion topic and decides on this because I > don't see in technical issue in calling it a library. The naming is just a choice. Yesterday morning it was called lib/gpu/ and in the evening it was renamed lib/gpudev/ so no technical issue :) But the design of the API with queues or other paradigm is something I would like to discuss here. Note: there was no intent to publish GPU processing control in DPDK 21.08. We want to focus on GPU memory in 21.08, but I understand it is a key decision in the big picture. What would be your need and would you design such API? > > > Something similar to > > > http://code.dpdk.org/dpdk/v21.05/source/lib/regexdev/rte_regexdev.h#L27 > > > Could you share how "running tasks" translates to the above scheme > > > like other her dpdk device libraries? > > > > We will share our view soon but what to control in GPU execution > > must be a community discussed requirement. > > Makes sense.