From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id BA765A054F;
	Wed, 10 Feb 2021 14:33:17 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 41BB340693;
	Wed, 10 Feb 2021 14:33:17 +0100 (CET)
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
 by mails.dpdk.org (Postfix) with ESMTP id DC6B240142
 for <dev@dpdk.org>; Wed, 10 Feb 2021 14:33:15 +0100 (CET)
IronPort-SDR: Hya4TBcvZXvH4saweA4IpXFf89EjNZrZaWkxPOLGLfF3L4ekrwapND03liZ3fbzNkTjg8l+eHl
 UdC+VROUcIVA==
X-IronPort-AV: E=McAfee;i="6000,8403,9890"; a="246135936"
X-IronPort-AV: E=Sophos;i="5.81,168,1610438400"; d="scan'208";a="246135936"
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
 by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 10 Feb 2021 05:33:14 -0800
IronPort-SDR: M3WNt+LEFeQCzbIpbWpfTmWYRLV2EVGDLl2SwDduwMwFSVS/aH64n9EzGni5EGPUcMZtalnKXz
 yC0VPtrFh8pw==
X-IronPort-AV: E=Sophos;i="5.81,168,1610438400"; d="scan'208";a="488750348"
Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.247.83])
 ([10.213.247.83])
 by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 10 Feb 2021 05:33:11 -0800
To: Tal Shnaiderman <talshn@nvidia.com>, dev@dpdk.org
Cc: thomas@monjalon.net, pallavi.kadam@intel.com, dmitry.kozliuk@gmail.com,
 navasile@linux.microsoft.com, dmitrym@microsoft.com,
 david.marchand@redhat.com
References: <20210106194543.14024-1-talshn@nvidia.com>
 <20210106203553.9876-1-talshn@nvidia.com>
 <20210106203553.9876-3-talshn@nvidia.com>
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Message-ID: <f653ae61-a7d0-dc29-ae93-32bd75bcd7a5@intel.com>
Date: Wed, 10 Feb 2021 13:33:04 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <20210106203553.9876-3-talshn@nvidia.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v9 2/2] eal: add generic thread-local-storage
 functions
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 06-Jan-21 8:35 PM, Tal Shnaiderman wrote:
> Add support for TLS functionality in EAL.
> 
> The following functions are added:
> rte_thread_tls_key_create - create a TLS data key.
> rte_thread_tls_key_delete - delete a TLS data key.
> rte_thread_tls_value_set - set value bound to the TLS key
> rte_thread_tls_value_get - get value bound to the TLS key
> 
> TLS key is defined by the new type rte_tls_key.
> 
> The API allocates the thread local storage (TLS) key.
> Any thread of the process can subsequently use this key
> to store and retrieve values that are local to the thread.
> 
> Those functions are added in addition to TLS capability
> in rte_per_lcore.h to allow abstraction of the pthread
> layer for all operating systems.
> 
> Windows implementation is under librte_eal/windows and
> implemented using WIN32 API for Windows only.
> 
> Unix implementation is under librte_eal/unix and
> implemented using pthread for UNIX compilation.
> 
> Signed-off-by: Tal Shnaiderman <talshn@nvidia.com>
> ---

I'm a bit late to the party as the patch has been merged already, but 
perhaps as a further enhancement, you could add rte_errno setting for 
errors? You seem to have it only for get() API but not for others, and 
you pass pthread_setspecific()'s return value unmodified, even though it 
might return an error. Presumably, these error codes would be different 
on Unix and Windows, so return values would effectively be potentially 
different on different OS's, so perhaps it's better to return -1 with 
rte_errno to indicate which specific error was seen.

-- 
Thanks,
Anatoly