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 8EFADA0A0F; Fri, 4 Jun 2021 17:20:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EFE664068F; Fri, 4 Jun 2021 17:20:55 +0200 (CEST) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) by mails.dpdk.org (Postfix) with ESMTP id 950E540147 for ; Fri, 4 Jun 2021 17:20:54 +0200 (CEST) Received: by mail-io1-f53.google.com with SMTP id k5so643473iow.12 for ; Fri, 04 Jun 2021 08:20:54 -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=/0SKRMgFJinio8iioWWKUEH1lKOeE9LYxLaM695pBho=; b=dpewlwwFQ/5/XJe8yIL9ZNBKL/wjN4wYz8cZVD3VJObmN8WJ185GFefdpLMdNbuyd4 TxNyVzfrXzeJjOHH39I4tAxEjCCT1buGeyP51D5VkpVhcfbNWjrvcaR6iD6+noUBC+UB ixDnKECMh+Y2IOJGCaS44CsKuBOo6LlSpq+0e5FcmNLEMvcxpmXdBjom29jtJWQOgOw0 EYWyCKWV536mLpYEKQ0xYht12xK7PzXCtUg8fdRet0P0A1QGBojjtp77OvQY7jEsgYth 0xA2AOgJ2IROxgXjkHTf4vjOkwshhqrpZjnajZ0Wvs9lioqBtybS4b7orJWpcHHFszTT Frcg== 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=/0SKRMgFJinio8iioWWKUEH1lKOeE9LYxLaM695pBho=; b=iityXpx4+MMQ17nHDBZ5wJXpJvQaWsNbJQCzgWLF7xsL5tIQeFlXUN+Vn3SYccUEKy IC6hqyv+soVZplpJ+i1pspHeQrDj34geHOw2ve6oZrXD15zP+F4rRy5O/7rbAhZr2c2r EvEaALASS/0dvYgG1HzCEHl5awp3QOlXvcKx15C8W0Bt5Jcah1P8UL9iUNoyvV4BRcHY XQwc/SWj0U+rAdMsYBLPvS8jQ5rJ0jvfhGOj6so86NxW67PtbEYIn0e5i3UaJXsO7p4S mELZdqLqSWeEse9vCYbRW5d1e32XQw6/+Yd19HpFtHKbqsu8kypzjAm62MhrBn9MHEyh PYHA== X-Gm-Message-State: AOAM533DDgEhQxu65RNMGzhQnfaX3xSjimAZQwaBcTRECceanIzgngob 1RESl1LB+54FNsqPN1bqSLMNezc26OlACrp/bHE= X-Google-Smtp-Source: ABdhPJx8MzBepNY4BI3Wbmd5Ury0cGhjWKJke3FUtj5CSphH6oLNXEAlI6tvesHp/gtOqTAViA1NEM/gVkuZU8OHv4g= X-Received: by 2002:a6b:c984:: with SMTP id z126mr4302118iof.94.1622820053788; Fri, 04 Jun 2021 08:20:53 -0700 (PDT) MIME-Version: 1.0 References: <20210602203531.2288645-1-thomas@monjalon.net> <2020675.CS5hdstByM@thomas> <1762355.HKltZAk3iZ@thomas> In-Reply-To: <1762355.HKltZAk3iZ@thomas> From: Jerin Jacob Date: Fri, 4 Jun 2021 20:50:37 +0530 Message-ID: To: Thomas Monjalon , Honnappa Nagarahalli Cc: Andrew Rybchenko , Ferruh Yigit , dpdk-dev , Elena Agostini , David Marchand 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 Fri, Jun 4, 2021 at 7:39 PM Thomas Monjalon wrote: > > 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 capabilities, which can suits > > >>>>>> better as extension to existing memory related library instead 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 notification > > >>>>> so we can integrate the GPU workload in a packet processing pipeline. > > >>>> > > >>>> 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 library. > > >>> > > >>> 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 capabilities, > > > 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 computing > 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. If your scope is something similar and No Graphics involved here then we can remove G. 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) I can think of "coprocessor-dev" as one of the name. 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. > > >