From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B87E5C47082 for ; Thu, 3 Jun 2021 09:34:04 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 4D6FE613DE for ; Thu, 3 Jun 2021 09:34:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4D6FE613DE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6637540E78; Thu, 3 Jun 2021 11:34:03 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id EEBB140DF6 for ; Thu, 3 Jun 2021 11:34:00 +0200 (CEST) IronPort-SDR: 4NTMYqYVmgZJeQOdYLkaN51Vs1TX7Cog4ej0DnuVLDaBQZ5Jf67TfR6Jrrnpb13PKlKnn/9ZEX HeE0niv0f++g== X-IronPort-AV: E=McAfee;i="6200,9189,10003"; a="202145557" X-IronPort-AV: E=Sophos;i="5.83,244,1616482800"; d="scan'208";a="202145557" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jun 2021 02:33:56 -0700 IronPort-SDR: 6m2Yb9WoGO8ND6HQ6LegRFjkXjJje31/Z66uLXvyRvRUNH27DkMBN9ZMMLweeF9ggJu+dykkVD VQ0cJAtm6E5g== X-IronPort-AV: E=Sophos;i="5.83,244,1616482800"; d="scan'208";a="480154872" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.232.124]) ([10.213.232.124]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jun 2021 02:33:55 -0700 To: Jerin Jacob , Thomas Monjalon Cc: dpdk-dev , Elena Agostini References: <20210602203531.2288645-1-thomas@monjalon.net> From: Ferruh Yigit X-User: ferruhy Message-ID: Date: Thu, 3 Jun 2021 10:33:51 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 6/3/2021 8:47 AM, Jerin Jacob wrote: > On Thu, Jun 3, 2021 at 2:05 AM Thomas Monjalon wrote: >> >> From: Elena Agostini >> >> The new library gpudev is for dealing with GPU from a DPDK application >> in a vendor-agnostic way. >> >> As a first step, the features are focused on memory management. >> A function allows to allocate memory inside the GPU, >> while another one allows to use main (CPU) memory from the GPU. >> >> The infrastructure is prepared to welcome drivers in drivers/gpu/ >> as the upcoming NVIDIA one, implementing the gpudev API. >> Other additions planned for next revisions: >> - C implementation file >> - guide documentation >> - unit tests >> - integration in testpmd to enable Rx/Tx to/from GPU memory. >> >> The next step should focus on GPU processing task control. >> >> Signed-off-by: Elena Agostini >> Signed-off-by: Thomas Monjalon >> --- >> .gitignore | 1 + >> MAINTAINERS | 6 + >> doc/api/doxy-api-index.md | 1 + >> doc/api/doxy-api.conf.in | 1 + >> doc/guides/conf.py | 8 ++ >> doc/guides/gpus/features/default.ini | 13 ++ >> doc/guides/gpus/index.rst | 11 ++ >> doc/guides/gpus/overview.rst | 7 + >> doc/guides/index.rst | 1 + >> doc/guides/prog_guide/gpu.rst | 5 + >> doc/guides/prog_guide/index.rst | 1 + >> drivers/gpu/meson.build | 4 + >> drivers/meson.build | 1 + >> lib/gpudev/gpu_driver.h | 44 +++++++ >> lib/gpudev/meson.build | 9 ++ >> lib/gpudev/rte_gpudev.h | 183 +++++++++++++++++++++++++++ >> lib/gpudev/version.map | 11 ++ >> lib/meson.build | 1 + >> 18 files changed, 308 insertions(+) >> create mode 100644 doc/guides/gpus/features/default.ini >> create mode 100644 doc/guides/gpus/index.rst >> create mode 100644 doc/guides/gpus/overview.rst >> create mode 100644 doc/guides/prog_guide/gpu.rst >> create mode 100644 drivers/gpu/meson.build >> create mode 100644 lib/gpudev/gpu_driver.h >> create mode 100644 lib/gpudev/meson.build >> create mode 100644 lib/gpudev/rte_gpudev.h >> create mode 100644 lib/gpudev/version.map >> >> diff --git a/.gitignore b/.gitignore >> index b19c0717e6..49494e0c6c 100644 >> --- a/.gitignore >> +++ b/.gitignore >> @@ -14,6 +14,7 @@ doc/guides/compressdevs/overview_feature_table.txt >> doc/guides/regexdevs/overview_feature_table.txt >> doc/guides/vdpadevs/overview_feature_table.txt >> doc/guides/bbdevs/overview_feature_table.txt >> +doc/guides/gpus/overview_feature_table.txt >> >> # ignore generated ctags/cscope files >> cscope.out.po >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 5877a16971..c4755dfe9a 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -452,6 +452,12 @@ F: app/test-regex/ >> F: doc/guides/prog_guide/regexdev.rst >> F: doc/guides/regexdevs/features/default.ini >> >> +GPU API - EXPERIMENTAL >> +M: Elena Agostini >> +F: lib/gpudev/ >> +F: doc/guides/prog_guide/gpu.rst >> +F: doc/guides/gpus/features/default.ini >> + >> Eventdev API >> M: Jerin Jacob >> T: git://dpdk.org/next/dpdk-next-eventdev >> diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md >> index 1992107a03..bd10342ca2 100644 >> --- 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? +1 Current RFC announces additional memory allocation capabilities, which can suits better as extension to existing memory related library instead of a new device abstraction library. > 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? > >> + /* GPU info structure. */