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 E091241D6C; Thu, 2 Mar 2023 09:52:18 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C538D40E09; Thu, 2 Mar 2023 09:52:18 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id EA51140DFB for ; Thu, 2 Mar 2023 09:52:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677747136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SOzsR1sLbD+ZwbdAnZWp9yUueSxJiV8zOFqUg0hxHCo=; b=KKltOK1o4U0J5FtCU/a7pgVh2lkNGd9ADZcTaDgob0B9N1YfuX1bKu425PEEM1DcsCGWMo DbDOQbmEIyn1yWltqQ/t8Pq4Bt0gz7g3icXGxjLtTsWj4VyE87bEOulUIKKul2cT/vSrDb n+VaRvdIVmdAlF05ReHE5En+6mulWWM= Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-633-N6ZB5EyPNvSRNJ87ewZR3Q-1; Thu, 02 Mar 2023 03:52:14 -0500 X-MC-Unique: N6ZB5EyPNvSRNJ87ewZR3Q-1 Received: by mail-pj1-f69.google.com with SMTP id q61-20020a17090a1b4300b00237d2fb8400so1150109pjq.0 for ; Thu, 02 Mar 2023 00:52:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677747134; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SOzsR1sLbD+ZwbdAnZWp9yUueSxJiV8zOFqUg0hxHCo=; b=R8Y5Q5nxM8Gq4switE+GbpS34kJC4WAE6zXgtlBUxyVLenG3xTjuL1Nw+zULGbDTa7 UBOZhtCzds9hYVVg6qkB9BKjKVEiwRAooBXwRFfzC7FpemWFQwf+SYXyMjUWj1hObYOv n9pJPDy1r0Dq2HAgSQl7PZytOMsXa1nBqTDLf1lC+UCBikkYP1hMXgCAkQ4uFC5lGbQn pV692zW2yqklDX1btgANQKWZf3kEMCZ5Fx8Ale4kmTWKZkHLbiRdJkwSDwG/LxLAQBTx j/xxXVnvGFKf8Duwh60JrnhDyL/RjmHqTytPETF5g+iofY2vN4csVNO4R7cKHLt9oQ8Z /j0w== X-Gm-Message-State: AO0yUKWiROvMPRojGtVWhRFIu1Vt31ERLzyBWQUUklPejnP6NrF3yUOu DxXi+nEfolxhmt6FuQJtsxNrtz3IxQNNKguBeGLhsfVGav14WPMSZ/ANueKsN5FT6ifNJfD4AMf c7rgfoH0K2y7cUCHdp7mLA0ZB X-Received: by 2002:a17:902:a3cc:b0:19a:fa2f:559e with SMTP id q12-20020a170902a3cc00b0019afa2f559emr526998plb.3.1677747133849; Thu, 02 Mar 2023 00:52:13 -0800 (PST) X-Google-Smtp-Source: AK7set/M836BWc0pQDErpd+edSH2nS/P19vgFxuY82dNHjtlpAqLZkhEEBs80IKdrN1RRVGM4MqyE/7G6KM0U0yqe5M= X-Received: by 2002:a17:902:a3cc:b0:19a:fa2f:559e with SMTP id q12-20020a170902a3cc00b0019afa2f559emr526990plb.3.1677747133521; Thu, 02 Mar 2023 00:52:13 -0800 (PST) MIME-Version: 1.0 References: <20230224081642.2566619-1-david.marchand@redhat.com> <20230224151143.3274897-1-david.marchand@redhat.com> <095511d4-4fbb-47a8-a8a5-f2a3b932c01f@app.fastmail.com> In-Reply-To: From: David Marchand Date: Thu, 2 Mar 2023 09:52:02 +0100 Message-ID: Subject: Re: [PATCH v2 00/20] Enable lock annotations on most libraries and drivers To: =?UTF-8?Q?Ga=C3=ABtan_Rivet?= Cc: dev@dpdk.org, Thomas Monjalon , Tyler Retzlaff X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, Feb 27, 2023 at 5:13 PM Ga=C3=ABtan Rivet wrote: > Ah ok, so if I understand correctly, DPDK would need to declare some > '__rte_lockable rte_mutex' and associated functions for transparent suppo= rt, > 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. > > Unless it happens, would it be possible to condition the thread-safety an= notations > to FREEBSD as well? > > Maybe have two versions of the annotations: > > __rte_exclusive_locks_required() /* Conditioned on clang */ > __pthread_exclusive_locks_required() /* Conditioned on glibc/pthread su= pport */ > > the first one to use on RTE types that can be declared with __rte_lockabl= e, > the second for pthread objects that we don't want to replace. > I know the namespace is not great so maybe named another way. > > The '#ifdef FREEBSD' ossifies the annotation support at the function leve= l, > when this is a matter of types. This impedance mismatch would mean large > changes if someone was to make this support evolve at some point. I don't see how it requires large changes with the current approach. The patches in this series are a matter of lines. If we come up with the right abstraction later, this uglyness will be remov= ed. In any case, I am running short of time for 23.03. I am missing reviews from driver maintainers, which is a pity. Thomas raised an eyebrow on the malloc: and mem: patches too. I will probably defer this series to the next release. --=20 David Marchand