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 05810A0A0A; Thu, 3 Jun 2021 12:05:01 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8DC1A40E78; Thu, 3 Jun 2021 12:05:01 +0200 (CEST) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) by mails.dpdk.org (Postfix) with ESMTP id 4AEFF40DF6 for ; Thu, 3 Jun 2021 12:05:00 +0200 (CEST) Received: by mail-il1-f177.google.com with SMTP id b14so4671538ilq.7 for ; Thu, 03 Jun 2021 03:05:00 -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=SBhV+a/j3dZTAsBg3uPqNqbrlF0epjm8rhuCj7Z/wNI=; b=VK5nxXcvmU9V0z7K+2Xx+PsFAH925jIzSY5LiyQU8HgLkY07ZYCkfKUXKP8biPCNYh vDKqXU/1Ja7vmzwLpyxNGfOPl8KMdnLicKSX6zkN+tmXHVFIB09JnSu2nVAeHqvWuVkY mPJKMShqA0sofzQlqgIZktoucNUdcYeN24398opqtHIsL9ZKnqrv4VbzlyHdFEQk7Xw4 erzu6nAMqGAAEVgR0Efzh87qQ8RSBy1NrswErFTxR0rt77Rwe3Ohb2WIpEk4rKImvnzV vdenI6maPUjBHjlRfFej+F2z4DuFT1LuCYfit7FqCL3qUDZgy+B6Ho8HgE510W/emaPN dvHw== 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=SBhV+a/j3dZTAsBg3uPqNqbrlF0epjm8rhuCj7Z/wNI=; b=gz0KlJhyAbcfH9lRKL+jl94Co4mIWg7zPjMyByLy7/j4r4Jp10+jwvMDDLZTLhJjX+ HndgFVlryPWIx+w4NpJIpjrpwKVVn+JFvvQMul9oDyNA2ioB/2uYWNuloQpVjHKumxIf lDI0Ku+OGFgpVWmUPw1p031YCz/R4cMUDjgMkpaSs5TMzjn6D1vYeT35dEzAZjlemX4v 3y2Y3sbwMZuBPht4UWuzD1adr/lcSAUJv1u4aR6lU+f4VirluCyiDHlx4E46fAHyJmjf VPAiLJvLvxTIeN2R7A2mgxGLa1zvlN782pnh6uLMu9BY+6r3NfQg5cD0H/qHtcXR3GVo CDbA== X-Gm-Message-State: AOAM533rQAtpn9ojZF+vGKaUSGDicWs6Vp7iD5jhp/L249sFJOLk+TcU AeDNMtxrwQu0ViY+Ss4Ec2QchHGmmRswTYx9Fao= X-Google-Smtp-Source: ABdhPJxyoN70qkBo7H1MQpBaVBpf1MMDcDyahB/Rua/f07UVHuAlLFEjyTOwe2vAwlpWwrrTjU+2G1lw3twtbomWS9E= X-Received: by 2002:a92:d08c:: with SMTP id h12mr4709903ilh.294.1622714699677; Thu, 03 Jun 2021 03:04:59 -0700 (PDT) MIME-Version: 1.0 References: <20210602203531.2288645-1-thomas@monjalon.net> <2479672.ZMpKsOhbnr@thomas> <2514191.Ay6nQiMiuT@thomas> In-Reply-To: <2514191.Ay6nQiMiuT@thomas> From: Jerin Jacob Date: Thu, 3 Jun 2021 15:34:43 +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 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? 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. > > > 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. > > >