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 F19ECA0A0A; Thu, 3 Jun 2021 11:20:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7E41B40E78; Thu, 3 Jun 2021 11:20:39 +0200 (CEST) Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) by mails.dpdk.org (Postfix) with ESMTP id A5CAA40DF6 for ; Thu, 3 Jun 2021 11:20:38 +0200 (CEST) Received: by mail-il1-f182.google.com with SMTP id v13so4855844ilh.13 for ; Thu, 03 Jun 2021 02:20:38 -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=tImaEefnrsCJF4V0BF4/mf45xmIHuSB298SV4IAy/5g=; b=qNrgVl0jXlM71Aa4Km5ERmJHv3diOeykPbr4HdsVETJlbRmRjGKB0grYHLTwEPC+pO v/uvkcG4WEJbxAomnn08Lj2ga6y1tQwKGxavd8ndSRSi/zbg5jPxQ4L3mw0s7eVC52Mz Up3AMK8PUZitcJLZQP/koM3bPc5YJcnzvfYteq2wKJBo6NTfPMTy0j4rMPxxdrIDqsfe Ol0VkT6dkYhE7T3ACWs6KEzbBsx9/HLEkfQ2smavFG0uqDXZQ3Us44r2X2rG8POZ8b9K 9nXgEYfeiBzGWNAR7NW589CNwv0v3+6mXvcpTyWeOdXbc3IHeTjuQcsz/hM4PRMFqkgz eQVw== 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=tImaEefnrsCJF4V0BF4/mf45xmIHuSB298SV4IAy/5g=; b=X53fSfwX1ZLQkVYLCeuMJkPHcrLZlHpAEYOtn/BABkEHjI6AycecdGl40P4AMZW0Gq eUXOuQup/rDZAN1ztSw9Vy9vaYWN5KXb3PpKlU5zW1uTZXZv+r6SLvxk/tflHevKvqit 8cd8LMAomwl0ribwL0PeoH18EhV9k/Lo0LvdVS+DiGHg90/jEoJ6xxwG389YtCoJbhS3 85Hfe5i358MIQtvMun6fSD8L5W+KddD9DiNyj0Bj7DAaAL6Yr+H3vwpnX8NfmbDa76Rh GXj3kvKWYDeF+t3bfGcDq56JA878st0WK00uzcweAAX7LLoXaRWFJA6jFqZUe6NiSYOn kSew== X-Gm-Message-State: AOAM531qBJukiSUkh0OoQCtndfpr9mb5bdZzXRRg9yOFEd8BvLRa4ZR2 GZ40XOX5OZIMbUkipCHgTXMS6G0LJJ848ozzFYw= X-Google-Smtp-Source: ABdhPJwLr7I6iZrQ7TIVr6N9oB4sMrlt7uP/qBQMVQFKHrg77o10vfXw5xdxb/zr0BzsZqKvOFVdoc5uFXDHSh+4840= X-Received: by 2002:a05:6e02:5d1:: with SMTP id l17mr19511599ils.162.1622712038041; Thu, 03 Jun 2021 02:20:38 -0700 (PDT) MIME-Version: 1.0 References: <20210602203531.2288645-1-thomas@monjalon.net> <3058202.9UA1LLGnyJ@thomas> <2479672.ZMpKsOhbnr@thomas> In-Reply-To: <2479672.ZMpKsOhbnr@thomas> From: Jerin Jacob Date: Thu, 3 Jun 2021 14:50:22 +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 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. 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. 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 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? > for running tasks. > >