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