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 9365BA0A0A; Thu, 3 Jun 2021 09:49:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6229340689; Thu, 3 Jun 2021 09:49:43 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id CA6354067A for ; Thu, 3 Jun 2021 09:49:41 +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 521847F519; Thu, 3 Jun 2021 10:49:41 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 521847F519 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1622706581; bh=4v4m0GV9SHfDCHaHzFTn5zMV8OrcQ6+TJl7IuH56XoA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=kzwYXrvOUg+4fT5lgQAcd92FGplTqOSRWd40pYjN/kdz3VN0WwuY9VT/DOzdTZCqx Xz8NJ51OPU4LH5ZNjsRysodg6Sf/B8oKjgY4Jg3o60TW7DtOUAGpaOJXDb0f4ht020 qh/7Q07OgnmpcTIzjMX8J8SeTGf9fGsPMG6bV0ow= To: Thomas Monjalon Cc: dev@dpdk.org, Elena Agostini , david.marchand@redhat.com References: <20210602203531.2288645-1-thomas@monjalon.net> <38e4c145-e561-0707-a3b1-17a8f6cee75e@oktetlabs.ru> <2561723.R1Na977jkj@thomas> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <0f3bdf41-ce07-caa4-289a-b05f6727bf0d@oktetlabs.ru> Date: Thu, 3 Jun 2021 10:49:41 +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: <2561723.R1Na977jkj@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/3/21 10:26 AM, Thomas Monjalon wrote: > 03/06/2021 09:06, Andrew Rybchenko: >> On 6/2/21 11:35 PM, Thomas Monjalon wrote: >>> + * Allocate a chunk of memory on the GPU. >> >> Looking a below function it is required to clarify here if >> the memory is visible or invisible to GPU (or both allowed). > > This function allocates on the GPU so it is visible by the GPU. > I feel I misunderstand your question. Below function says rte_gpu_malloc_visible() and its description highlights that allocated memory is visible to GPU. My problem that I don't understand what's the difference between these two functions. >>> + */ >>> +__rte_experimental >>> +int rte_gpu_malloc(uint16_t gpu_id, size_t size, void **ptr); >> >> May be *malloc() should return a pointer and "negative" >> values used to report various errnos? > > I don't understand what you mean by negative values if it is a pointer. > We could return a pointer and use rte_errno. I was talking about something like (void *)(-ENOMEM), but it is a bad idea. NULL + rte_errno is much better. However, may be I'd kept callback as is set rte_error in lib if negative value is returned by the callback. This way we'll be safe against lost rte_errno update in drivers.