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 4AF4FA0A0A; Thu, 3 Jun 2021 13:39:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B30FF40E78; Thu, 3 Jun 2021 13:39:03 +0200 (CEST) Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) by mails.dpdk.org (Postfix) with ESMTP id E317940DF6 for ; Thu, 3 Jun 2021 13:39:02 +0200 (CEST) Received: by mail-il1-f175.google.com with SMTP id r6so5218021ilj.1 for ; Thu, 03 Jun 2021 04:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ax1b8/XFk1VwtSb5OR3r6aJOaLwIpfKzpLo2MIqZhUk=; b=pcJzFRw5i5F1uJufVAHfUKFv1nq9UGyA7NURN7yGfIdHibbMx3XuKPNcDwmXEteWoy dYDIrICEZpOJQsrJkXCOFMnu4g8tq+P1fVij4AZZO/GiqgTMUK31byvKIc3I9zAD5YOV +yZy+ZMsIN2DRCXeiR+PAYSU/8VGPlKExsOGKHR/wZx7JIuKqWS1VqCuPjpoy1HJqBLq Naeq2V8DQK/6lWBU4n5r18hFK0u0k+Muzfx7h1JKCVEfoTNmM8rQc8Y+Ova1apd29+b7 czY43WO8gYkY8Xva4OooytcofnxXNs2Bs8CP1YocvCMQ12JlESSjjBoRZ4mLfkylawNn 734Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ax1b8/XFk1VwtSb5OR3r6aJOaLwIpfKzpLo2MIqZhUk=; b=XTZKRBVqHo1qrSms0ujy/tvk55AK4fsNeSlyhXhj9oWDKIfcNIj4EMa8aEEKjsoUOr MS2WB1dza27ko0LcPBK516QzeQEcnfO7rRuf/zBJuYeTiZhsDt4syDOhWzNpD3lNEikT 8+ut8sP1PmUaCBp0UicQ0QhBLtT51gIjM+rAiEcmzNf8v9aa5gVg8aqGBzzzwjp3I32l eckgQG22CTvKMeZiiqRpPV1PnOvfSep+dO/rnjZxlaiAGUL7xewNkKJTF0n94mwV7Tel cFaFpsxWYba1B6t1ZIIMxxFrLt/K8zDfByzfxpgv0oXekYoObsNBJKjpUykn5jJjm1OB xBiw== X-Gm-Message-State: AOAM530F1NqDI3YRy1cmbCaowNoM3cWWlP1bGifie2BKeXElToQnFMuP HWrSx5fF6BLn1ztUrMV2401Uvl63+bhZh1+35ZY= X-Google-Smtp-Source: ABdhPJxu+A72iopv+HxocDep8CDzEc/fKCXQmtRUr6LjZSjcErt43lKHfPJC3XgTPDLCwJPg5HQs14REmYLTQ4VzPPY= X-Received: by 2002:a05:6e02:5d1:: with SMTP id l17mr19947079ils.162.1622720342199; Thu, 03 Jun 2021 04:39:02 -0700 (PDT) MIME-Version: 1.0 References: <20210602203531.2288645-1-thomas@monjalon.net> <2514191.Ay6nQiMiuT@thomas> <7088348.icZg66Z9Yi@thomas> In-Reply-To: <7088348.icZg66Z9Yi@thomas> From: Jerin Jacob Date: Thu, 3 Jun 2021 17:08:45 +0530 Message-ID: To: Thomas Monjalon Cc: dpdk-dev , Elena Agostini Content-Type: text/plain; charset="UTF-8" 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" On Thu, Jun 3, 2021 at 4:00 PM Thomas Monjalon wrote: > > 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. rte_secuity has drivers but it is not called a device library. > 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. > 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. > > > > > 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. > > >