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.