From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (xvm-189-124.dc0.ghst.net [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6BB23A09FF; Tue, 5 Jan 2021 12:53:48 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E877C16080C; Tue, 5 Jan 2021 12:53:47 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 64F3116080B for ; Tue, 5 Jan 2021 12:53:47 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 93ECA5C00EB; Tue, 5 Jan 2021 06:53:46 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 05 Jan 2021 06:53:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= jQ3jf9K531ba8f5gTRwLe1xxGv2yTMpAssxdHrlUyVc=; b=jcz5Tyq4hNyClSsl KYZCl/+WA2DzKWbeoTd85es+59lIvpm0UPtRw/QjEiYxLoStfaRspSEfWDZpO3/o EVS1SiZaJuM1/LEpQiUSFVplFkkWjP2wfheFnQdzcfr/I2hYBkdyVRLEECr7O7pY O+/sGMIOrq+zmfr9Cq/dK9AUl+ofRv1so6u02h03ku4pfr1k7cTam2+7QMRPB/Ln nWQvc4T9i0Vs9unlI5FG7HeAbNIJNFMXi3YlhXtfsB2+aebgKv26LxESPLPKgcNB ZmCHggCqYUQz/Ka3lUdsA84E47VmLNseOecvqOZOF4yrsUzM29msYMjL2KKuDWMq jh4G+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=jQ3jf9K531ba8f5gTRwLe1xxGv2yTMpAssxdHrlUy Vc=; b=HioYVQZEE8WYQQIilbUJg0FUTNkN+3cA3jnq6wlr01tmGTtJBz+qwIbdM 3zwWCpq5IVssGxBLoavvqLX8OGqtAsLCNhzRTgu9l24THeThHs6TDB2/tjzZ3TJt AQsuVnxkQ22ZRRHP6d2HqCR/tiESgcYsz+pWCTsigmUXYodaFpD9BRTbS2SCFnHS wehYqkbXQCfKbDPU/Zs9Oei1JtVCt8ctlv6s7sA3ClM742K3yaPLXdTYU/pwCB7g iIUCQH8R3D4Mv2mflGtfmulvtkoA2dNSeCf5rjNSiJLNy1NuUiuPfd4yzeLNl3FQ n8XzNOOutbOvnnKZ/sTGie2wmsaWQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdefhedgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 12C5F1080059; Tue, 5 Jan 2021 06:53:44 -0500 (EST) From: Thomas Monjalon To: Tal Shnaiderman Cc: dev@dpdk.org, pallavi.kadam@intel.com, dmitry.kozliuk@gmail.com, navasile@linux.microsoft.com, dmitrym@microsoft.com, david.marchand@redhat.com Date: Tue, 05 Jan 2021 12:53:43 +0100 Message-ID: <2119244.Rpp8axq6Fq@thomas> In-Reply-To: <20201230111244.13832-1-talshn@nvidia.com> References: <20201226160848.9824-1-talshn@nvidia.com> <20201230111244.13832-1-talshn@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 30/12/2020 12:12, Tal Shnaiderman: > Add support for tls functionality in EAL. You should write TLS uppercase here and below. There is already a TLS capability in rte_per_lcore.h, using __thread keyword. Note: I think the historical wording "lcore" is confusing. We talk about lcore, assuming the thread is bound to its lcore. Please explain in the patch why the more complex TLS functions are required, i.e. can __thread variable be used in Windows? limitation, etc. > The following functions are added: > rte_thread_tls_create_key - function to create a tls data key. > rte_thread_tls_delete_key - function to delete a tls data key. > rte_thread_tls_set_value - function to set value bound to the tls key > rte_thread_tls_get_value - function to get value bound to the tls key We can assume the TLS key logic is known, but this patch is the right place to explain it. > tls key will be defined by the new type rte_tls_key > > Windows implementation is under librte_eal/windows and > implemented using WIN32 API for Windows only. > > common implementation is under librte_eal/common and > implemented using pthread for UNIX and Windows compilation > using extenral pthread libraries, when supported. typo: external [...] > v3: switch from pthread shim to generic eal implementation [DmitryK] > v4: modify file names, function names, move unix code to common > for future external pthreads support [DmitryK] For now, there is no external pthread library. It did not have been discussed generally in the techboard. As it is using the Unix pthread API, it sounds more logical to have this implementation in the Unix sub-directory I think. > --- a/lib/librte_eal/common/meson.build > +++ b/lib/librte_eal/common/meson.build > + 'rte_thread.c', [...] > --- a/lib/librte_eal/include/meson.build > +++ b/lib/librte_eal/include/meson.build > + 'rte_thread.h', There are existing functions in rte_lcore.h and rte_per_lcore.h which are managing threads. I think a prior patch should move such functions in rte_thread files. At least we can start moving the affinity functions, which are not using pthread types as parameters. > --- /dev/null > +++ b/lib/librte_eal/include/rte_thread.h > @@ -0,0 +1,88 @@ > +/* SPDX-License-Identifier: BSD-3-Clause > + * Copyright(c) 2020 Mellanox Technologies, Ltd > + */ > + > +#include Why do you need rte_compat? > +/** > + * Function to create a TLS data key visible to all threads in the process > + * function need to be called once to create a key usable by all threads. > + * rte_tls_key is an opaque pointer used to store the allocated key. > + * and optional destructor can be set to be called when a thread expires. You may explain that the key is later used to get/set a value. > + * > + * @param key > + * Pointer to store the allocated rte_tls_key > + * @param destructor > + * The function to be called when the thread expires. > + * Not supported on Windows OS. What happens when specifying a destructor on Windows? > + * > + * @return > + * On success, zero. > + * On failure, a negative number. > + */ > +__rte_experimental > +int > +rte_thread_tls_create_key(rte_tls_key *key, void (*destructor)(void *)); For .h files, we have the return type on the same line (I know it is stupid). I would suggest moving the verb "create" at the end of the function names. [...] > +rte_thread_tls_delete_key(rte_tls_key key); Could be rte_thread_tls_key_delete? [...] > +rte_thread_tls_set_value(rte_tls_key key, const void *value); rte_thread_tls_value_set? > +rte_thread_tls_get_value(rte_tls_key key); rte_thread_tls_value_get?