From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 20C31A04DB;
	Thu, 15 Oct 2020 10:28:43 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id E2C761DD30;
	Thu, 15 Oct 2020 10:28:41 +0200 (CEST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com
 [64.147.123.20]) by dpdk.org (Postfix) with ESMTP id 32D711DD2D
 for <dev@dpdk.org>; Thu, 15 Oct 2020 10:28:40 +0200 (CEST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
 by mailout.west.internal (Postfix) with ESMTP id 1F4A9FBA;
 Thu, 15 Oct 2020 04:28:38 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute2.internal (MEProxy); Thu, 15 Oct 2020 04:28:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding:content-type; s=fm2; bh=
 gvPtgvz0xDwi3nhULXtSCnAOTK0hfg4qWfnwJKfTY/4=; b=WmDMp15mwa74LsPg
 X74zfDuqPYVAoq/+GVuW2ek9/8z/urUmJS3EJI8ijADvFbxxP+pKvarDmMVRT1P/
 g7+FkeJoXPiQAkCPtptYtrHkTOgdHSdVP/iDk5sAV2TXyXr2L5kg/yxHwSCqqEo1
 EgkCLdSL93FYEQn+PmbdaNrAzJrAXqC8gbwvepS8zZbPiFvXEW8KTUcQN0IB45me
 IaAjSAoJ5Lop+qvNhNyhpUhFdRv11+VR2EON0A3azBV5C7/jlnC6WHptudTAej5k
 tmRYnU1WBeKiK89FdQWbrso5Oo6d+JDjcgCyS+pOq/vN7NXz0kKa4jw028HOGx5F
 Bd9Ylw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm1; bh=gvPtgvz0xDwi3nhULXtSCnAOTK0hfg4qWfnwJKfTY
 /4=; b=lDW94PIaL4YmMmbaj8I0FEG0rv7kE+9OK172MKl1xV4XqAMLKYBlVWqXP
 ZHa5zCNDxP39Ktt7ixEq33w8ZpQ3Ov23QdBMwpT6H6MxR7vA+rihUro1r2eaNBQ8
 Ky9nltpUm1b9lcjtl6KlalG+WhzfK7KRHIRak2ogJKWS+espnijMHKnITET+rVFX
 rOx47IdjMmMO3mr39PYAmrevZ5TUR6f4NSOQZvICo54r31W5++vovbNBb+4uPL7R
 SlD735wyLRi49fQSCZJAmDTFkQc2gvZKCvRPKaJvIh1cchGhhDpkTI58JUb5PjK3
 nj3LM1NuY1aFLKpNkEJTt8q/DaZdA==
X-ME-Sender: <xms:NAiIX0JrNDICZBV4ht2fajVXtlwRx3Fra_z3Ot0Dqm4g5-lT0KoMrA>
 <xme:NAiIX0ITfd1VF0ukPLecRJ4TSSfTINl8F_7DRC7WKqabq-SZGON9Slr1YRFWqab5n
 wQPdA4e6seHL9UoYw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieefgddtgecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs
 ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf
 frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei
 iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih
 iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho
 nhdrnhgvth
X-ME-Proxy: <xmx:NAiIX0vXxqG924IPQKRnSTp2hD2wcwagK3I2lWSVGPMXsbqlO1DZ2g>
 <xmx:NAiIXxZ5Hk8ZZ-3W9YLUftPSSyhhdkXjald2tQpXngX-iU3ZiNRqKg>
 <xmx:NAiIX7YWTwHzWPlRd181QR2iFXMyjuoBrbIMwC69vJcuik-cdzIcJg>
 <xmx:NQiIX6kEZlkaPr70fT6QE372SKCj0T9W7IXnEmyyyd7mGTB7YYU6ww>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id 5CE993064674;
 Thu, 15 Oct 2020 04:28:36 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Suanming Mou <suanmingm@nvidia.com>
Cc: Ori Kam <orika@nvidia.com>, Ferruh Yigit <ferruh.yigit@intel.com>,
 Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, dev@dpdk.org
Date: Thu, 15 Oct 2020 10:28:35 +0200
Message-ID: <2847989.Y1bzbvb2tm@thomas>
In-Reply-To: <1602724067-390536-3-git-send-email-suanmingm@nvidia.com>
References: <1601194817-208834-1-git-send-email-suanmingm@nvidia.com>
 <1602724067-390536-1-git-send-email-suanmingm@nvidia.com>
 <1602724067-390536-3-git-send-email-suanmingm@nvidia.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH v5 2/2] ethdev: make rte_flow API thread safe
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

15/10/2020 03:07, Suanming Mou:
> Currently, the rte_flow functions are not defined as thread safe.
> DPDK applications either call the functions in single thread or
> protect any concurrent calling for the rte_flow operations using
> a lock.
> 
> For PMDs support the flow operations thread safe natively, the
> redundant protection in application hurts the performance of the
> rte_flow operation functions.
> 
> And the restriction of thread safe is not guaranteed for the
> rte_flow functions also limits the applications' expectation.
> 
> This feature is going to change the rte_flow functions to be thread
> safe. As different PMDs have different flow operations, some may
> support thread safe already and others may not. For PMDs don't
> support flow thread safe operation, a new lock is defined in ethdev
> in order to protects thread unsafe PMDs from rte_flow level.
> 
> A new RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE device flag is added to
> determine whether the PMD supports thread safe flow operation or not.
> For PMDs support thread safe flow operations, set the
> RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE flag, rte_flow level functions will
> skip the thread safe helper lock for these PMDs. Again the rte_flow
> level thread safe lock only works when PMD operation functions are
> not thread safe.
> 
> For the PMDs which don't want the default mutex lock, just set the
> flag in the PMD, and add the prefer type of lock in the PMD. Then
> the default mutex lock is easily replaced by the PMD level lock.
> 
> The change has no effect on the current DPDK applications. No change
> is required for the current DPDK applications. For the standard posix
> pthread_mutex, if no lock contention with the added rte_flow level
> mutex, the mutex only does the atomic increasing in
> pthread_mutex_lock() and decreasing in
> pthread_mutex_unlock(). No futex() syscall will be involved.
> 
> Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
> Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Acked-by: Ori Kam <orika@nvidia.com>
> Acked-by: Matan Azrad <matan@nvidia.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>