From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DB64C433ED for ; Fri, 30 Apr 2021 06:37:17 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 7EFC661077 for ; Fri, 30 Apr 2021 06:37:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7EFC661077 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5C85F40688; Fri, 30 Apr 2021 08:37:15 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 4352740395 for ; Fri, 30 Apr 2021 08:37:13 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1059) id 7F74A20B7188; Thu, 29 Apr 2021 23:37:12 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 7F74A20B7188 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1619764632; bh=PXHYgfs0E5kAQ1vT+3gRLZbsjnupaoPZ79qhpVR1GZQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YhXG0VXolPdeaezRs7oMul/C4KVULzQfP+EXHbTQ8pTXxIRMD0RYO4jeXQitC61Io gTC2wqZXVbEqjC5ft3pBIhuP3bJ35lUwkLZ7Ank8Ibjpl995iC4vRIN/C8/KSuk7NU To/fIbZXsXjM/aPKjIDMDJyx9iiuPAqsS3/IkoZ8= Date: Thu, 29 Apr 2021 23:37:12 -0700 From: Narcisa Ana Maria Vasile To: Dmitry Kozlyuk Cc: "Kinsella, Ray" , Thomas Monjalon , dev@dpdk.org, khot@microsoft.com, navasile@microsoft.com, dmitrym@microsoft.com, roretzla@microsoft.com, talshn@nvidia.com, ocardona@microsoft.com, bruce.richardson@intel.com, david.marchand@redhat.com, pallavi.kadam@intel.com Message-ID: <20210430063712.GA3115@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1617057640-24301-2-git-send-email-navasile@linux.microsoft.com> <1617413948-10504-2-git-send-email-navasile@linux.microsoft.com> <20210429035029.349d3306@sovereign> <33056936.xYFp2keEGj@thomas> <20210429192826.6a2b1c9d@sovereign> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210429192826.6a2b1c9d@sovereign> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dpdk-dev] [PATCH v6 01/10] eal: add thread id and simple thread 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" On Thu, Apr 29, 2021 at 07:28:26PM +0300, Dmitry Kozlyuk wrote: > 2021-04-29 13:05 (UTC+0100), Kinsella, Ray: > > On 29/04/2021 08:44, Thomas Monjalon wrote: > > > 29/04/2021 02:50, Dmitry Kozlyuk: > > >> 2021-04-02 18:38 (UTC-0700), Narcisa Ana Maria Vasile: > > >>> --- /dev/null > > >>> +++ b/lib/librte_eal/windows/include/rte_windows_thread_types.h > > >>> @@ -0,0 +1,12 @@ > > >>> +/* SPDX-License-Identifier: BSD-3-Clause > > >>> + * Copyright(c) 2021 Microsoft Corporation > > >>> + */ > > >>> + > > >>> +#ifndef _RTE_THREAD_TYPES_H_ > > >>> +#define _RTE_THREAD_TYPES_H_ > > >>> + > > >>> +#include > > >>> + > > >>> +typedef DWORD rte_thread_t; > > >>> + > > >>> +#endif /* _RTE_THREAD_TYPES_H_ */ > > >> > > >> pthread_t type in pthreads-win32 and winpthread is not 32 bit. > > >> DPDK will have different ABI depending on a threading backend used. > > >> Apps must know it at build time then. How do they discover it? > > >> This is worth a warning in commit log and docs. > > > > > > Not sure this is an acceptable behaviour. > > > In my opinion, ABI should not vary. > > > +Cc Ray > > > > > > > So pthread_t on Win32 should just map to the HANDLE datatype. > > Which if memory serves is in fact a DWORD on Win32. > > DWORD = uint32_t, HANDLE = void*, which are of different size on x64. > I suggest an opaque 64-bit value to fit pthread_t from MinGW's winpthread. > Only pthreads-win32 has a bigger pthread_t, but we don't have to support it. > > > So I suspect that pthreads indirection is probably be just providing a circuitous route to end up in the same place, a HANDLE > > > > IMHO > > To absolutely guarantee no ABI change, we ought to be passing back void * not rte_thread_t. > > Yes. Only I'd use a type-safe version: > > typedef struct rte_thread_tag { > void *opaque; /* or uintptr_t per Tyler's suggestion */ > } rte_thread_t; I agree we need a big enough value to fit different identifiers. However, just to clarify, on Windows, there are two distinct thread-related identifiers: thread id (DWORD) and thread HANDLE (void*). In this API implementation I've used the rte_thread_t as the DWORD thread identifier, as the HANDLE can be obtain from this DWORD using the OpenThread() function. I will implement an opaque value that will be assigned the thread id (not the HANDLE) in this API.