From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6C5D7A04B7; Wed, 14 Oct 2020 12:19:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E63051DDDB; Wed, 14 Oct 2020 12:19:33 +0200 (CEST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by dpdk.org (Postfix) with ESMTP id 05FCF1DDD8 for ; Wed, 14 Oct 2020 12:19:31 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 809F2F4E; Wed, 14 Oct 2020 06:19:29 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 14 Oct 2020 06:19:29 -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= DtCMiIbYIIk9CS/qj0ZxtKn+G4Cp4om6jQImmHPdooM=; b=hazy+BMRziRiBhrl Iiwa/lWemdef0t2eo1TEiYWuYF54CkpWX+iXxTNFWW5Y4TnkJhH2692pYUOtjbxs G1QZ1cDzavzvjsOtZdVARN8zilPD9uHCAzJQ9lVvIFC/tD0qvNNOmdRJD+NDGb7F JtbplI5g0fo6fB9ZM9NwZ3ju4uDpVlBA8NL2ra/EvQXwrCOXpb3ukdS2JxRe8kbM Yo3M4xF2EqGrrmNswMt9y9GsNgLG7z5F5eXi9juxj3BtyRZC4cqteHy6hQqp9ZRe tVjH734FaqGamODTmR485huAaRsD3n+V8us3pTlxS5mcfWe41aw2iK5+1ONNuvyq Eh/+1g== 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=DtCMiIbYIIk9CS/qj0ZxtKn+G4Cp4om6jQImmHPdo oM=; b=k1NLIrrG3ZqZMgmabA7L+PvwVAxuIvVyOfPUlmKgd0LndWf2zXM7ZR05M +PCoxfshqpeCCT9wOkrnnLR2Jb7KppcbF4leaA3W8pE4xw04ZsW1g8tS5F0b6tfz x0jmT7nM4xoKb+wVicoRTSnMyXfnmd4rMEFfZidipn4OTRHMtTBH8SvnPDw3bTS5 +7rQaKFlBqdBXfY5UK7PmtcSkzWeLKpn2EApTYxekQ8F3kDHaiybUxWcKUGJHH0o zdEYhZpxLt3eaykbe9N+uo8G+MtIiQXBcBhAWYCqa0AyzgXOcp45QnAzz7rmls9c 2YYSGwnVYwuWaDoShL4/ZnFzL5vPw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedriedugddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 21A703064684; Wed, 14 Oct 2020 06:19:27 -0400 (EDT) From: Thomas Monjalon To: Suanming Mou Cc: Ori Kam , Ferruh Yigit , Andrew Rybchenko , dev@dpdk.org Date: Wed, 14 Oct 2020 12:19:26 +0200 Message-ID: <2778778.5oPTP038Qd@thomas> In-Reply-To: <1602206243-157603-3-git-send-email-suanmingm@nvidia.com> References: <1601194817-208834-1-git-send-email-suanmingm@nvidia.com> <1602206243-157603-1-git-send-email-suanmingm@nvidia.com> <1602206243-157603-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 v4 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 09/10/2020 03:17, Suanming Mou: > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > +If PMD interfaces do not support re-entrancy/multi-thread safety, rte_flow "API" should be inserted here to make clear which layer we talk about. > +level functions will do it by mutex per port. The application can test the "do it" is too vague. I suggest "protect threads". > +dev_flags with RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE in struct rte_eth_dev_data The application access it through dev_info. > +to know if the rte_flow thread-safe works under rte_flow level or PMD level. Again insert "API": rte_flow API level This sentence can be confusing. Better to say explicitly that if RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE is set, it means the protection at API level is disabled. > +Please note that the mutex only protects rte_flow level functions, other > +control path functions are not in scope. Please find a complete rewording with sentences split after punctuation: If PMD interfaces do not support re-entrancy/multi-thread safety, the rte_flow API functions will protect threads by mutex per port. The application can check whether ``RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE`` is set in ``dev_flags``, meaning the PMD is thread-safe regarding rte_flow, so the API level protection is disabled. Please note that this API-level mutex protects only rte_flow functions, other control path functions are not in scope. [...] > --- a/doc/guides/rel_notes/release_20_11.rst > +++ b/doc/guides/rel_notes/release_20_11.rst > @@ -109,6 +109,12 @@ New Features > * Extern objects and functions can be plugged into the pipeline. > * Transaction-oriented table updates. > > +* **Added thread safe support to rte_flow functions.** > + > + Added ``RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE`` device flag to indicate > + if PMD support thread safe operations. If PMD doesn't set the flag, > + rte_flow level functions will protect the flow operations with mutex. > + Should be sorted before drivers with other ethdev features if any. [...] > --- a/lib/librte_ethdev/rte_ethdev.h > +++ b/lib/librte_ethdev/rte_ethdev.h > +/** Device PMD supports thread safety flow operation */ "Device" is useless safety -> safe (adjective before "flow operation") It becomes: /** PMD supports thread-safe flow operations */ > +#define RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE 0x0001 OK for the name of the flag. [...] > --- a/lib/librte_ethdev/rte_ethdev_core.h > +++ b/lib/librte_ethdev/rte_ethdev_core.h > @@ -180,6 +183,7 @@ struct rte_eth_dev_data { > * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags. > */ > > + pthread_mutex_t fts_mutex; /**< rte flow ops thread safety mutex. */ "ts" or "safety" is redundant for a mutex. I suggest "flow_ops_mutex" as a name.