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 72F58A0A0F; Fri, 4 Jun 2021 15:59:05 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E54074068F; Fri, 4 Jun 2021 15:59:04 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id E89F140147 for ; Fri, 4 Jun 2021 15:59:02 +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 5B79F7F529; Fri, 4 Jun 2021 16:59:02 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 5B79F7F529 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1622815142; bh=oNo0K829vr8vrB4baG0YehqYPFT3zZb2jinxVcQ5eQ4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Qp3IgHt8sGM1ekemmGlIXyIQLp/8BAL+CSBmUtnb3O+dcLmMbKWeME7DzAwWB17eT MQKy+VEyqJujyh2BWzZTfwGvBQUsw913zN7DQxMGC6Wdm+KLR56yy0dZfAx1fzv0Or hw7zrnyvvEFjKlIQx0pnKxWGB+rVLKdGNrkdoXZM= To: Thomas Monjalon Cc: Jerin Jacob , Ferruh Yigit , dpdk-dev , Elena Agostini , david.marchand@redhat.com References: <20210602203531.2288645-1-thomas@monjalon.net> <1817476.i3Lo7XacKO@thomas> <2020675.CS5hdstByM@thomas> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Fri, 4 Jun 2021 16:59:02 +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: <2020675.CS5hdstByM@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 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. >> I.e. why GPU? NIC can have own memory and provide corresponding API. > > So far we don't need to explicitly allocate memory on the NIC. > The packets are received or copied to the CPU memory. > In the GPU case, the NIC could save the packets directly > in the GPU memory, thus the need to manage the GPU memory. > > Also, because the GPU program is dynamically loaded, > there is no fixed API to interact with the GPU workload except via memory. > >> What's the difference of "the memory on the CPU that is visible from the >> GPU" from existing memzones which are DMA mapped? > > The only difference is that the GPU must map the CPU memory > in its program logic. I see. Thanks for the explanations.