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 2E8E1A0A0F; Fri, 4 Jun 2021 20:20:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9C9A14068F; Fri, 4 Jun 2021 20:20:41 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id C9CFF40147 for ; Fri, 4 Jun 2021 20:20:38 +0200 (CEST) IronPort-SDR: 4MqVtGAHgCTUrwXw1FRxB/JfbppoI/Bowzgf1QQzKeLat1vRiXzPVuKlL5L2RiMgRkwLmUh6o2 zUImjiegBCzg== X-IronPort-AV: E=McAfee;i="6200,9189,10005"; a="289974786" X-IronPort-AV: E=Sophos;i="5.83,248,1616482800"; d="scan'208";a="289974786" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2021 11:20:32 -0700 IronPort-SDR: o2OhDkBWDw2uIljeXB92CPN89PIT32Ehtntq+inGN5kTixBF+lHjrl8fvaI+JJoEKTIUaVXOAN EhacziudCoMA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,248,1616482800"; d="scan'208";a="412451846" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmsmga007.fm.intel.com with ESMTP; 04 Jun 2021 11:20:32 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Fri, 4 Jun 2021 11:20:31 -0700 Received: from orsmsx605.amr.corp.intel.com (10.22.229.18) by ORSMSX612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Fri, 4 Jun 2021 11:20:31 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx605.amr.corp.intel.com (10.22.229.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4 via Frontend Transport; Fri, 4 Jun 2021 11:20:31 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.47) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Fri, 4 Jun 2021 11:20:31 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U86lm8fpzl34FGlTFJj6nEl5fIjyuYtlAFtsHPvD3UgdUzJiHpxuqxVn8gUnbGjD29KRIZbco/EltfcU3B+2Ihg7qrUadldsELnT97gN1cLP8bsqcF7W504NNj0sUTj0pcIgy6oq+FAskmLNYELXBUWDl8NBXSyuG1XK4HKkDXdYwn/nYLPRDppPi9jfqkoeWnjC8mFrX9B4wUR7Zac9OjvqKawSHXrfS98PqdeN6dKB/viZ8lMnMOQYjVT7LftWJe8lh59yPVfahGPzwrPuE447mjEKjIkq3A9/eVjvISjiB+Q8AEGjaYQE/Kek/C8qwNdwlcwDj3DN8Gx4sGu9Ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zSpwKkdlOtR9E1ym/GP8MX4tN92BVEKmQwo0je0nGd8=; b=Zz1pgycwXCRj2TZ5cWwRSznbBxG27DTqKx4uO9vIIjBquVkagU3dZvpZO/e4+E/VzBDlDxIUdKPBDoIIcHZhsUFP6bjq++cyzJmRddldx9dtr1pQ9iZTqnMyuDWVuphg3r+6hMnaYxqUXJ428dLCsi9FnzuvaAn2QLyhe6wawXA16Pc+1izuA8oV6d4bBUCfspwXntCoQ7OaDgqAfSEkUltjCOgv8knymQpWXJx/ytPj2kVSI6vkva2XJin+CO2YEnOzTGPP6pvD5nZLjWZLRojGiuhyvahGF07hj8MnPnX3UQRfDPvgXoy+4/XG/GjM/H00AJMJB1Xc0ziIurmLPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zSpwKkdlOtR9E1ym/GP8MX4tN92BVEKmQwo0je0nGd8=; b=bkgNlYKjN21Tfrgqsnxocp1oUawsYhwbQK5SGQLHVgcRNyQGoxe1JctTv4ncP8sxRfHvRT2lLbX1VvJQw/Sy6x6UHBMLyPwXA2ZxCaj+rOtG/jNhna83WMmN+ZNU65PYLn6ayK01cvOoA4Dn1QkOI4bL8Pq2KEZe+6TepsV6Vj4= Received: from BN8PR11MB3795.namprd11.prod.outlook.com (2603:10b6:408:82::31) by BN9PR11MB5548.namprd11.prod.outlook.com (2603:10b6:408:105::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.23; Fri, 4 Jun 2021 18:20:29 +0000 Received: from BN8PR11MB3795.namprd11.prod.outlook.com ([fe80::8807:6661:e425:102]) by BN8PR11MB3795.namprd11.prod.outlook.com ([fe80::8807:6661:e425:102%7]) with mapi id 15.20.4195.025; Fri, 4 Jun 2021 18:20:29 +0000 From: "Wang, Haiyue" To: Thomas Monjalon , Jerin Jacob CC: Honnappa Nagarahalli , Andrew Rybchenko , "Yigit, Ferruh" , dpdk-dev , Elena Agostini , "David Marchand" Thread-Topic: [dpdk-dev] [PATCH] gpudev: introduce memory API Thread-Index: AQHXV+8BBxLOVwnssEGBVBOBXmJb5asB6ZqAgAAdp4CAAaGkAIAAC2mAgAAbJQCAAAVVgIAAA7EAgAALNACAAALqgIAAE+KAgAAIoICAAClD4A== Date: Fri, 4 Jun 2021 18:20:29 +0000 Message-ID: References: <20210602203531.2288645-1-thomas@monjalon.net> <1762355.HKltZAk3iZ@thomas> <2385250.mgn969muHi@thomas> In-Reply-To: <2385250.mgn969muHi@thomas> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.0.76 authentication-results: monjalon.net; dkim=none (message not signed) header.d=none;monjalon.net; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.142.30] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9cf20e31-5ff9-46eb-17f3-08d927856eca x-ms-traffictypediagnostic: BN9PR11MB5548: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: e3H+99FT8dQ1RAMnng86K4qV9YVlXJ6LM6kp5eorxO25q0z3BK3TCJHKH03O6HJkfU0C2r8rgBFYURFYjzj6XAOe1axJ6CkOS0i727foHLhfMRs5DCl/JQBI8OzXZC/+t/XGn0hXBz9ofxzb5OPDDiI/vA+JfcFGyBGuUr/9dS7ejqW/CdUNOqSlnW71tWqzJ8MJaSlIF1WuOVlFnW6AJI3mqBmtXXeZEo8vYotRr2lg8IrGoH5RB/RQrOs5paADiArxPWi1RDAYyGeFZi3v/LxrB3VDY4Qx48OJXBUV8p/ztIeyIcTXdImu9+6ZlN4MmuJvPRsXVkzNU14JItZLsdIuOnKZOte0YojuPPt6dvvf6YX9W4zHZ3KIZY6ki6G0UsWaJnGQbojlRjgTFLmPO55+Z1KSyd8+QIhAhWa5vhd8Cp++5iE21KMqgeNVzKcox0Y51HPZtMifdVQ3595Z8eDN8SmCxtFOCiQ5PD5zFR06Yrc5U01kNrpbnxffUWXp43TCcVO1jN/Qfn2oU4up15vL1ExoNFMTs8wmos/2wgX6yblS9cJHV39ITPjLaWNJYbvH1M0xei/uurd4GrFyqgEqE9j/cGCOnVtAg78mp9xebWMmXSuDOguElEE16PfbrhWm2eFR4V18VgxciLDfEl6uTOJE/DJ84l/4eQiQySdP5MAP9dMB/lXoe1IFwLB8OwpEOrpT3aVjoakVTUNHii6XQ5F1rnjg/vvIvePTEpg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR11MB3795.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(366004)(376002)(136003)(396003)(8676002)(71200400001)(9686003)(66446008)(55016002)(54906003)(122000001)(2906002)(52536014)(110136005)(316002)(5660300002)(8936002)(86362001)(38100700002)(6506007)(66946007)(7696005)(966005)(83380400001)(76116006)(478600001)(53546011)(186003)(4326008)(26005)(64756008)(66556008)(66476007)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?2Rtjf0RSV3iLoOv+0broPMDQmQRLwZOTjXxzBSwWkLECHHjV+x1cd5AehrIH?= =?us-ascii?Q?G2O1gCs42TYGusmQggs/Fra4JU1eamy9aOcmHamGibx3wJZ4MyQGss6wNWMP?= =?us-ascii?Q?wgjmU/0EJY8a6Xkym10dPhH+VM4VL3KK242Um8knvrOYdLKaRPyUnpl5z6Xf?= =?us-ascii?Q?xrJrm+ckckbRa5CGQUqWPWtY01mrQrVNBgvAL50Xi8JaEAY8O0QA2l+qHV9f?= =?us-ascii?Q?8BToxlZT9a1WFl28wBnLJwOjKA+rjfyL2c6NZHhmKH95FjHqRxVGO+fFYiFO?= =?us-ascii?Q?tTO6uh1jAxZ3hjuuejU5ymTAr1MFHyf5OeZHPCXRQAe5egbHhYNtUz2RhFpf?= =?us-ascii?Q?0aP8oxdAvx2fDFE4ueu2AGJIicub4y1RKOSLQWuazz6oWRELQMluArKUhbhY?= =?us-ascii?Q?POsDoUFO2QxQUyD6qJlrR1Qv8xVxAmrTXhIgHAolTizHksO9cI14D8hDGaL7?= =?us-ascii?Q?ha4dN+GW+EEpyy4tjjV/24uefl+jKiTGqbbogbWwJd5Q6XezaQekcrNbJsbV?= =?us-ascii?Q?pDH1ImoudgmfIbvbBgDSNlzOlIhJmr9WpQT+YJrvhHy6rDHWqMvwja0TLfZv?= =?us-ascii?Q?e3Lo1E8Pxyt7MpCqevZp8Mirjj8AUCX+xN6nfcCJgPVxglzYR0PiJGBC4O9G?= =?us-ascii?Q?brpVFYYMeXB+q7Sg9Ri8gjkX9NY1Y3QeZo4HoHJ1teKGsGoa86uJntcJY4Mm?= =?us-ascii?Q?6yNzgG8C3aMZ2nGStgGF4SRU0mfDelnoHisEeCyXtHjLulVRgY0JfKbzA0y+?= =?us-ascii?Q?3VvS6TPeHJVv29JA/OOMrpOZGonzf1wCs6C2IarSLh63hxYgNO5gxj1yw2L9?= =?us-ascii?Q?vAkeQi4SMlEFmMhWNNTCAHChzHnO2Vo0yBANqdbzRIAKt9IXzC64lsA2MDAP?= =?us-ascii?Q?GVnN2aj6XewuRoAN37KtFiUKsuRZA6AEjZhmNZwtVUDVEYy7KcXjgu7wZUdq?= =?us-ascii?Q?MX4hdJAgcGLed1VjMt0s1mF53PcCsNoOPNNYjgtiPT6C4eGuNkwwd41305nD?= =?us-ascii?Q?PuLloL0n8nsfYe2LbX6tSsGYgBVJwR1bG2MlE1QEKXjf3tvJ2/NFYUAydzJ2?= =?us-ascii?Q?lFX2cOEblpowjGT+UxGLDnhprV+W7KdCkfsMZKCQSIrySN/O4Kcy2A9kr5SU?= =?us-ascii?Q?T5LzSi2A0+dpRlyRaEo873/rvdeSIS0JW7HHFD8+6/dF9UVZkn00RN19IA2j?= =?us-ascii?Q?8328zrA2PWbuOKkamiouklS+uyXvFCSa0JT2xIQYSKbDGuG/V7sHPlOjb5V3?= =?us-ascii?Q?JXZbfqyeDTb38WM84Cw81dJQOvaYBqtM+5OiShdcn4+n90HY+OId2YbGTj3v?= =?us-ascii?Q?UeOKEafRwFRk4U1LNvP7M09P?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN8PR11MB3795.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9cf20e31-5ff9-46eb-17f3-08d927856eca X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2021 18:20:29.0778 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: X6MrdtOMfhagDsiyNuCTx4QmLPf+ZsrWjmItqXRKkoSEkRIAaZX+ZLXDSTdTJiMm2sd31s7iaHmsdSx1xejWXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR11MB5548 X-OriginatorOrg: intel.com 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" > -----Original Message----- > From: dev On Behalf Of Thomas Monjalon > Sent: Friday, June 4, 2021 23:51 > To: Jerin Jacob > Cc: Honnappa Nagarahalli ; Andrew Rybchenko > ; Yigit, Ferruh ; = dpdk-dev ; > Elena Agostini ; David Marchand > Subject: Re: [dpdk-dev] [PATCH] gpudev: introduce memory API >=20 > 04/06/2021 17:20, Jerin Jacob: > > On Fri, Jun 4, 2021 at 7:39 PM Thomas Monjalon wr= ote: > > > 04/06/2021 15:59, Andrew Rybchenko: > > > > On 6/4/21 4:18 PM, Thomas Monjalon wrote: > > > > > 04/06/2021 15:05, Andrew Rybchenko: > > > > >> On 6/4/21 3:46 PM, Thomas Monjalon wrote: > > > > >>> 04/06/2021 13:09, Jerin Jacob: > > > > >>>> On Fri, Jun 4, 2021 at 3:58 PM Thomas Monjalon wrote: > > > > >>>>> 03/06/2021 11:33, Ferruh Yigit: > > > > >>>>>> On 6/3/2021 8:47 AM, Jerin Jacob wrote: > > > > >>>>>>> On Thu, Jun 3, 2021 at 2:05 AM Thomas Monjalon wrote: > > > > >>>>>>>> + [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 capabilit= ies, which can suits > > > > >>>>>> better as extension to existing memory related library inste= ad of a new device > > > > >>>>>> abstraction library. > > > > >>>>> > > > > >>>>> It is not replacing mempool. > > > > >>>>> It is more at the same level as EAL memory management: > > > > >>>>> allocate simple buffer, but with the exception it is done > > > > >>>>> on a specific device, so it requires a device ID. > > > > >>>>> > > > > >>>>> The other reason it needs to be a full library is that > > > > >>>>> it will start a workload on the GPU and get completion notifi= cation > > > > >>>>> so we can integrate the GPU workload in a packet processing p= ipeline. > > > > >>>> > > > > >>>> I might have confused you. My intention is not to make to fit = under mempool API. > > > > >>>> > > > > >>>> I agree that we need a separate library for this. My objection= is only > > > > >>>> to not call libgpudev and > > > > >>>> call it libgpu. And have APIs with rte_gpu_ instead of rte_gpu= _dev as > > > > >>>> it not like existing "device libraries" in DPDK and > > > > >>>> it like other "libraries" in DPDK. > > > > >>> > > > > >>> I think we should define a queue of processing actions, > > > > >>> so it looks like other device libraries. > > > > >>> And anyway I think a library managing a device class, > > > > >>> and having some device drivers deserves the name of device libr= ary. > > > > >>> > > > > >>> I would like to read more opinions. > > > > >> > > > > >> Since the library is an unified interface to GPU device drivers > > > > >> I think it should be named as in the patch - gpudev. > > > > >> > > > > >> Mempool looks like an exception here - initially it was pure SW > > > > >> library, but not there are HW backends and corresponding device > > > > >> drivers. > > > > >> > > > > >> What I don't understand where is GPU specifics here? > > > > > > > > > > That's an interesting question. > > > > > Let's ask first what is a GPU for DPDK? > > > > > I think it is like a sub-CPU with high parallel execution capabil= ities, > > > > > and it is controlled by the CPU. > > > > > > > > I have no good ideas how to name it in accordance with > > > > above description to avoid "G" which for "Graphics" if > > > > understand correctly. However, may be it is not required. > > > > No strong opinion on the topic, but unbinding from > > > > "Graphics" would be nice. > > > > > > That's a question I ask myself for months now. > > > I am not able to find a better name, > > > and I start thinking that "GPU" is famous enough in high-load computi= ng > > > to convey the idea of what we can expect. > > > > > > The closest I can think of is big-little architecture in ARM SoC. > > https://www.arm.com/why-arm/technologies/big-little > > > > We do have similar architecture, Where the "coprocessor" is part of > > the main CPU. > > It is operations are: > > - Download firmware > > - Memory mapping for Main CPU memory by the co-processor > > - Enq/Deq Jobs from/to Main CPU/Coprocessor CPU. >=20 > Yes it looks like the exact same scope. > I like the word "co-processor" in this context. >=20 > > If your scope is something similar and No Graphics involved here then > > we can remove G. >=20 > Indeed no graphics in DPDK :) > By removing the G, you mean keeping only PU? like "pudev"? > We could also define the G as "General". >=20 > > Coincidentally, Yesterday, I had an interaction with Elena for the > > same for BaseBand related work in ORAN where > > GPU used as Baseband processing instead of Graphics.(So I can > > understand the big picture of this library) >=20 > Yes baseband processing is one possible usage of GPU with DPDK. > We could also imagine some security analysis, or any machine learning... >=20 > > I can think of "coprocessor-dev" as one of the name. >=20 > "coprocessor" looks too long as prefix of the functions. >=20 > > We do have similar machine learning co-processors(for compute) > > if we can keep a generic name and it is for the above functions we may > > use this subsystem as well in the future. >=20 Accelerator, 'acce_dev' ? ;-) > Yes that's the idea to share a common synchronization mechanism > with different HW. >=20 > That's cool to have such a big interest in the community for this patch. >=20