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 D1135A0C3F; Sat, 12 Jun 2021 04:39:18 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4AA784014F; Sat, 12 Jun 2021 04:39:18 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 27D5C4003F for ; Sat, 12 Jun 2021 04:39:16 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1059) id 36AD720B7178; Fri, 11 Jun 2021 19:39:15 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 36AD720B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1623465555; bh=Kx6URABMNqpU/uzEEYBMeFjlcNfCb4uybBjo5bPQZ08=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Xi+D0UKB9V7l7WQNBiR3dNY2n1EdKxFaTJtcRuwmQEynLAKeDNKkmVbUzrP7IhVfw Xv0Uhp0VBpdEv/EPx2/yQgITn6z4Y5JLAKUih5Idk4wMO+ozZqPYw6/KDKaV5Bjiek 2xt8jj8VDInN6h6OCG+zgNZLw7djhTzdBbBDy2XE= Date: Fri, 11 Jun 2021 19:39:15 -0700 From: Narcisa Ana Maria Vasile To: Dmitry Kozlyuk Cc: dev@dpdk.org, thomas@monjalon.net, 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: <20210612023915.GA1288@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1622849908-5710-1-git-send-email-navasile@linux.microsoft.com> <1622850274-6946-1-git-send-email-navasile@linux.microsoft.com> <1622850274-6946-8-git-send-email-navasile@linux.microsoft.com> <20210609020419.6671302f@sovereign> <20210610013717.00a96602@sovereign> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210610013717.00a96602@sovereign> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dpdk-dev] [PATCH v9 07/10] eal: implement functions for mutex management 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, Jun 10, 2021 at 01:37:17AM +0300, Dmitry Kozlyuk wrote: > 2021-06-09 02:04 (UTC+0300), Dmitry Kozlyuk: > > 2021-06-04 16:44 (UTC-0700), Narcisa Ana Maria Vasile: > > [...] > > > diff --git a/lib/eal/include/rte_thread_types.h b/lib/eal/include/rte_thread_types.h > > > index d67b24a563..7bb0d2948c 100644 > > > --- a/lib/eal/include/rte_thread_types.h > > > +++ b/lib/eal/include/rte_thread_types.h > > > @@ -7,4 +7,8 @@ > > > > > > #include > > > > > > +#define RTE_THREAD_MUTEX_INITIALIZER PTHREAD_MUTEX_INITIALIZER > > > + > > > +typedef pthread_mutex_t rte_thread_mutex_t; > > > + > > > #endif /* _RTE_THREAD_TYPES_H_ */ > > > diff --git a/lib/eal/windows/include/rte_windows_thread_types.h b/lib/eal/windows/include/rte_windows_thread_types.h > > > index 60e6d94553..c6c8502bfb 100644 > > > --- a/lib/eal/windows/include/rte_windows_thread_types.h > > > +++ b/lib/eal/windows/include/rte_windows_thread_types.h > > > @@ -7,4 +7,13 @@ > > > > > > #include > > > > > > +#define WINDOWS_MUTEX_INITIALIZER (void*)-1 > > > +#define RTE_THREAD_MUTEX_INITIALIZER {WINDOWS_MUTEX_INITIALIZER} > > > + > > > +struct thread_mutex_t { > > > + void* mutex_id; > > > +}; > > > + > > > +typedef struct thread_mutex_t rte_thread_mutex_t; > > > + > > > #endif /* _RTE_THREAD_TYPES_H_ */ > > > > In previous patches rte_thread content was made opaque and of equal size > > for pthread (most implementations) and non-pthread variant. > > AFAIU, we agree on the requirement of compatible ABI between variants, > > that is, a compiled app can work with any threading variant of DPDK. > > Above definition of `rte_thread_mutex_t` does not satisfy it. > > Or do we only promise API compatibility? > > This is the most important question now. > > From Windows community call 2021-06-10, for everyone's information. > > 1. Yes, binary compatibility is a requirement. > > 2. Static mutex initializer for Windows is tricky (an old topic). > This patch proposes `rte_mutex` to hold a pointer to actual mutex > and use NULL as static initializer, then allocate on first use. > At the same time we want to use the same initializer for pthread variant. > This means it would also need indirection, allocation, and tricky logic. > > My opinion: > > New threading API can just be without static initilizer. > All it usages in DPDK could be converted to dynamic initialization > either in appropriate function or using `RTE_INIT`. > Maybe create a convenient macro to declare a static mutex and its > initialization code, what do others think? > > RTE_STATIC_MUTEX(private_lock) > > Expanding to: > > static RTE_DECLARE_MUTEX(private_lock) > RTE_DEFINE_MUTEX(private_lock) > > > Expanding to: > > static rte_mutex private_lock; > > RTE_INIT(__rte_private_lock_init) > { > RTE_VERIFY(rte_thread_mutex_init(&private_lock)); > } > > As a bonus it removes the need of `rte_*_thread_types.h`. Thank you Dmitry, I think this is the best and most elegant solution. I will use a pointer to represent the mutex: typedef struct rte_thread_mutex_tag { void* mutex_id; } rte_thread_mutex; ..and use the macro for static initializations as you described.