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 30E93428BF; Mon, 3 Apr 2023 17:36:59 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B88C840ED7; Mon, 3 Apr 2023 17:36:58 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 304AC40A7E for ; Mon, 3 Apr 2023 17:36:57 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id 4B6B2210CB25; Mon, 3 Apr 2023 08:36:56 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 4B6B2210CB25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1680536216; bh=zHIWOVYFQcguda0oZa15NTByejGkXMGBKNMMqf640jk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Anvozklmz95SV4Irs6OTG3NQ7BTG9CpB0ORwaPTHLu0rSNU+pm8T9qZCdYmNqQeRe 1YeREH2IWnehWYoDjof3awBuoNxxJk1+vjuKBIRrODNdiqlumgCwAK8A2oREco/mVT 71+fp8aWJibCR6PRJ2Fz4kOBu8YxvYfBqLq/47t0= Date: Mon, 3 Apr 2023 08:36:56 -0700 From: Tyler Retzlaff To: David Marchand Cc: dev@dpdk.org, Thomas Monjalon , =?iso-8859-1?Q?Ga=EBtan?= Rivet Subject: Re: [PATCH v2 00/20] Enable lock annotations on most libraries and drivers Message-ID: <20230403153656.GA6670@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20230224081642.2566619-1-david.marchand@redhat.com> <20230224151143.3274897-1-david.marchand@redhat.com> <095511d4-4fbb-47a8-a8a5-f2a3b932c01f@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 On Mon, Apr 03, 2023 at 12:52:06PM +0200, David Marchand wrote: > Hello Tyler, > > On Thu, Mar 2, 2023 at 9:52 AM David Marchand wrote: > > On Mon, Feb 27, 2023 at 5:13 PM Gaëtan Rivet wrote: > > > Ah ok, so if I understand correctly, DPDK would need to declare some > > > '__rte_lockable rte_mutex' and associated functions for transparent support, > > > to wrap above the pthread API. > > > > Yes, this is what I had in mind for the mid/long term but it was too > > late for 23.03 after -rc1. > > > > The Windows porting effort will probably need this abstraction too as > > we are trying to stop relying on the pthread API. > > I don't see this item in Microsoft roadmap, though. > > Do you have an opinion on this topic? Okay, trying to grok the question here. If the question is do we want to introduce a mutex/condition variable and lock/unlock signal/wait abstraction? I would certainly like to see reduced conditional compilation that applications have to perform for the platform features. I also really would like to purge the remaining pthread_{mutex,condvar} shim since it is unsightly. With msvc I think we could probably achieve the same with C11 threads but I haven't investigated feasability and said with no investigation older glibc may not provide the optional feature. In the absence of C11 threads we can provide an rte_ abstraction but I don't think I can put it on the roadmap until basic msvc support is stood up (a question of resource prioritization as always). I could commit to looking at it once msvc and atomics changes are merged the earliest possible time frame for that is the start of the 23.11 cycle. If that happens at decent velocity I could even see adding it to 23.11 roadmap. For now if someone else decides to introduce an abstraction I would just caution strongly not to remove __rte_experimental from any API added until I get a chance to focus on it. ty > > Thanks. > > -- > David Marchand