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=-3.8 required=3.0 tests=BAYES_00,DKIM_ADSP_DISCARD, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 75D77C07E94 for ; Fri, 4 Jun 2021 13:05:47 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 5881D611C1 for ; Fri, 4 Jun 2021 13:05:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5881D611C1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=oktetlabs.ru 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 6B77F4068F; Fri, 4 Jun 2021 15:05:45 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 1DD3540147 for ; Fri, 4 Jun 2021 15:05:44 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 8ADF97F529; Fri, 4 Jun 2021 16:05:43 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 8ADF97F529 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1622811943; bh=FipxJ4XfLSmNEQllch7+ai38uL4x6LS8j6MeS5Ozwls=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=gTBNDd0by5g4WIVbFaHy7cYKZEuJaP9S2QRdpCqEQMQTuvUeX9E7QbZa/08a/D8IF dHCfzIdJmmAUPHPWh7GPv26MQu2GlJmMcVye8asTcLBnhR9r8tR2ntYSFnFfbUzNie X92pNBDO4mrUn7lCsqcQuESv5+kEioReCzXC0N8k= To: Thomas Monjalon , Jerin Jacob Cc: Ferruh Yigit , dpdk-dev , Elena Agostini , david.marchand@redhat.com References: <20210602203531.2288645-1-thomas@monjalon.net> <2043513.c5GKn8Mpaa@thomas> <1817476.i3Lo7XacKO@thomas> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Fri, 4 Jun 2021 16:05:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <1817476.i3Lo7XacKO@thomas> 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/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? I.e. why GPU? NIC can have own memory and provide corresponding API. What's the difference of "the memory on the CPU that is visible from the GPU" from existing memzones which are DMA mapped?