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 4E834A0540; Wed, 6 Jul 2022 21:20:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2EC4B4069D; Wed, 6 Jul 2022 21:20:54 +0200 (CEST) Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by mails.dpdk.org (Postfix) with ESMTP id 3F12B40691 for ; Wed, 6 Jul 2022 21:20:53 +0200 (CEST) Received: by mail-pj1-f50.google.com with SMTP id fz10so9983215pjb.2 for ; Wed, 06 Jul 2022 12:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=HaImAUimXwAsVeG63NA0szJyojm4Ks36eIwuIDj2990=; b=1h6FNofwdWwC5IudEWaRQ8Dm7Xg5WUGcaXc6HA12VqA2/rR2C2p/Zsh0duKy+tXGcJ BoZIC0Y5vVM+AvffHEcBaov7swDWDXNrodqtY8AxHHKJ26PmkbSGHfZRRiPIuPjxgaSu K4TMRQKUsfo2OY4nyzt/GtHj5tEvqQgIJWe4LkrmRoiR+cGH/0tObAD4xFEL6UShwnhH TunnnPC8a88twnnTkAEQWi3HusllX+CIpFxbDFrDE/H0kCBfcTEA9wbMXJIZvKPT0t0c i/+SYvBPCisTG2raUA31ixJp8A6HUkrUP9BgTyeE+MNpCaVgqF7bdJjHB4FNdnAbiJ7Y pkCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=HaImAUimXwAsVeG63NA0szJyojm4Ks36eIwuIDj2990=; b=wA8y1tauvC/TfJl1wzVbdyN94TFMsY18cvOe7GZeE+EwqOOfPIuRZUCgQUxMvykWDe HEvaYi6ijVWJHAkfHDRWth3bjq+ibeIwJ2O5j3YuetKG/CLILC9ZqfhJTMrMh2Vnd5HA qDwCVhWN4Q9nybXedV2iCtjlK3YzZEx5lIMAqT2kBAZ5EfXA2qpBz6OEkTPasPXf5Fd9 mteQEbyxwP0PZCcW0kP8Aoo7HsmHQ44aSIFbXMscFLVrYH035TH4N9P8N6SHL73f6r1U rTMkMNCdI4+HkpOWW/KG1F0g0WeJml9zk28ZR6GqQSnwTSvU5uXOcQGvXoQA17vtSVz/ Yo2A== X-Gm-Message-State: AJIora9E8rggUyQx2woPG1iEVQe0fm8/7vMLSY3uEyKK0uyM7JbaW9st nvZaW8dOS58v1xQifRGP23nVSQ== X-Google-Smtp-Source: AGRyM1uj9Mt3n5ETm1UDcbIUTgmMHpZokDZiyPdIqRHILZrT0DVbIUR9DbIcnCrnlmQzrw8uHo4PvQ== X-Received: by 2002:a17:902:d706:b0:16b:960e:e689 with SMTP id w6-20020a170902d70600b0016b960ee689mr45540422ply.24.1657135252283; Wed, 06 Jul 2022 12:20:52 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id u15-20020aa7838f000000b0052592a8ef62sm22276357pfm.110.2022.07.06.12.20.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jul 2022 12:20:50 -0700 (PDT) Date: Wed, 6 Jul 2022 12:20:48 -0700 From: Stephen Hemminger To: Tom Rix Cc: Nicolas Chautru , dev@dpdk.org, thomas@monjalon.net, gakhil@marvell.com, hemant.agrawal@nxp.com, maxime.coquelin@redhat.com, mdr@ashroe.eu, bruce.richardson@intel.com, david.marchand@redhat.com Subject: Re: [PATCH v4 7/7] bbdev: add a lock option for enqueue/dequeue operation Message-ID: <20220706122048.46555c19@hermes.local> In-Reply-To: <25b4ece1-8f67-f119-7a0e-5b133f4e571c@redhat.com> References: <1655491040-183649-6-git-send-email-nicolas.chautru@intel.com> <1657067022-54373-1-git-send-email-nicolas.chautru@intel.com> <1657067022-54373-8-git-send-email-nicolas.chautru@intel.com> <25b4ece1-8f67-f119-7a0e-5b133f4e571c@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Wed, 6 Jul 2022 12:01:19 -0700 Tom Rix wrote: > On 7/5/22 5:23 PM, Nicolas Chautru wrote: > > Locking is not explicitly required but can be valuable > > in case the application cannot guarantee to be thread-safe, > > or specifically is at risk of using the same queue from multiple threads. > > This is an option for PMD to use this. > > > > Signed-off-by: Nicolas Chautru > > --- > > lib/bbdev/rte_bbdev.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h > > index b7ecf94..8e7ca86 100644 > > --- a/lib/bbdev/rte_bbdev.h > > +++ b/lib/bbdev/rte_bbdev.h > > @@ -407,6 +407,8 @@ struct rte_bbdev_queue_data { > > struct rte_bbdev_stats queue_stats; /**< Queue statistics */ > > enum rte_bbdev_enqueue_status enqueue_status; /**< Enqueue status when op is rejected */ > > bool started; /**< Queue state */ > > + rte_rwlock_t lock_enq; /**< lock protection for the Enqueue */ > > + rte_rwlock_t lock_deq; /**< lock protection for the Dequeue */ > > No. > > This is a good idea but needs a use before introducing another element, > particularly a complicated one like locking > > Tom Having two locks on same cacheline will create lots of ping/pong false sharing. Also, unless the reader is holding the lock for a significant fraction of the time a regular spin lock will be faster.