From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 69ED2A0A0F;
	Fri,  4 Jun 2021 14:55:35 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id ECFF94068F;
	Fri,  4 Jun 2021 14:55:34 +0200 (CEST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
 [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 5DFAE40147
 for <dev@dpdk.org>; Fri,  4 Jun 2021 14:55:33 +0200 (CEST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46])
 by mailout.nyi.internal (Postfix) with ESMTP id 087675C0112;
 Fri,  4 Jun 2021 08:55:33 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute6.internal (MEProxy); Fri, 04 Jun 2021 08:55:33 -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=
 /MfcfYgtstVpqESLvPZmX5FvrvLoYOqarr2VOPfIzfE=; b=2Nv/v3XkBtSl5xdU
 Z9R3zrN9pUHgBtQRm3tkJecifoh6K/kCWdLf9SZqj1MvtNKXh3Os3GyUc3/FTsXv
 WxGB+QqpeDw/gBCcAmkwGdbzKAW703DT1SZI2OUEW75EnGHHH+TT9/WwovPzF7KN
 QfrZP0McAoORa5D8f7/MTGJygZKJa/75KhcUVHJKG7AoR/4zo76iEDn9ZAjY/CLx
 r/rAquap08ckwizk1Km7EYfpFPYVcxo1MyIZ6xmKGoIqABUlJGMP3T3wapYu2vNJ
 8os2pL2YKbE+mKR1R7D2VfvvaLu/TekBW18HPGuuzH+1Armtg61MVqQ1oSYVRULO
 b1uQlQ==
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=/MfcfYgtstVpqESLvPZmX5FvrvLoYOqarr2VOPfIz
 fE=; b=STzRfzEZFgkCTj37bPI0n3ANNWsuO+CcC59/bXp1hTbrSjRXC0+AHZ1C7
 wktEgcDkKY9ViAMJUsETPvr/85SHin+k7JMJobvTu0RQe03tDHLkBMbtrLp/W2rO
 N0T6EOYJc2ynQiiXQDWj+D3f0h/QyoNDi6a3f91c8V5vU+wdaMT7o/HuGrqUxm8E
 08C+IMYJ5GMAfFh2ZO6uhktvhICD3fRt8oVswF+CseF2jxhRn/aTbinjX3UnIutw
 gllos6lNQ0ltYA3I0z0Gn0bt94rDsl+J9Orr0PBROIVRSUOsjx2xyZZ0Ui1W5V0U
 AHeh3DrczKtm4RGrDLz2ikRl7SEWw==
X-ME-Sender: <xms:xCK6YDujnBIx2xlISqxGROVdYo8ICSv9lDUvcqcY2zCehuATp_aEfw>
 <xme:xCK6YEeespOnFibhqujZuSZsapGomqxx46ur0Pe_-1mZ6-sF47L5Spd5TavXVBCRM
 6HxBm-TuwZgcciIaw>
X-ME-Received: <xmr:xCK6YGyGFdDEpg4nY1WFsL9K9FtbiT9MyYP7pHg4L3ZOHiC1fhUIYjKyeFvMQ5kH_9BUa_sYf9WkXmf0qYjlqAFbsA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtuddgheekucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
 shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg
 ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu
 ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh
 homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:xCK6YCOwYshMS3F0FvA9aQFewOn7V9J5rzBnDtRnhyHIpTvKsHVEkQ>
 <xmx:xCK6YD81zPL2OR--_XH_y9YlUVBvpZzHbq8HHkOfBAiUbuL2N87idA>
 <xmx:xCK6YCXiwxE3n086JNZFjVVT5ob4zn16trztvNRq05W2TjaqREs9XQ>
 <xmx:xSK6YFILS7Gv_jL0WaLNdhSyFdb73EtM95sshh-Ic0gUhWYoX8QXow>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 4 Jun 2021 08:55:31 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: dev@dpdk.org, Elena Agostini <eagostini@nvidia.com>, ferruh.yigit@intel.com
Date: Fri, 04 Jun 2021 14:55:30 +0200
Message-ID: <10019605.gdN4zKLbKd@thomas>
In-Reply-To: <CALBAE1OOPtxDh26C2TQq4DV2ivKk4rYnk9SpaxhU5dJVjDmq1w@mail.gmail.com>
References: <20210602203531.2288645-1-thomas@monjalon.net>
 <7088348.icZg66Z9Yi@thomas>
 <CALBAE1OOPtxDh26C2TQq4DV2ivKk4rYnk9SpaxhU5dJVjDmq1w@mail.gmail.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

03/06/2021 13:38, Jerin Jacob:
> On Thu, Jun 3, 2021 at 4:00 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > 03/06/2021 12:04, Jerin Jacob:
> > > On Thu, Jun 3, 2021 at 3:06 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > 03/06/2021 11:20, Jerin Jacob:
> > > > > 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.
> 
> rte_secuity has drivers but it is not called a device library.

rte_security is a monster beast :)
Yes it has rte_security_ops implemented in net and crypto drivers,
but it is an API extension only, there is no driver dedicated to security.

> > About mempool, it started as a standard lib and got extended for HW support.
> 
> Yes. We did not change to device library as it was fundamentally
> different than another DPDK deices
> when we added the device 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.
> 
> Not sure.
> 
> > 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.
> 
> Yeah, That is important. IMO, That defines what needs to be a device library.
> 
> > 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.
> 
> if the scope is only memory allocation, IMO, it is better to make a library.

No it is only the first step.

> > What would be your need and would you design such API?
> 
> For me, there is no need for gpu library(as of now). May GPU consumers
> can define what they need to control using the library.

We need to integrate GPU processing workload in the DPDK workflow
as a generic API.
There could be 2 modes:
	- queue of tasks
	- tasks in an infinite loop
In both modes, we could get completion notifications
with an interrupt/callback or by polling a shared memory.