All of lore.kernel.org
 help / color / mirror / Atom feed
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 <arybchenko@solarflare.com>,
	dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v4 2/2] ethdev: make rte_flow API thread safe
Date: Wed, 14 Oct 2020 12:19:26 +0200	[thread overview]
Message-ID: <2778778.5oPTP038Qd@thomas> (raw)
In-Reply-To: <1602206243-157603-3-git-send-email-suanmingm@nvidia.com>

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.




  reply	other threads:[~2020-10-14 10:19 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-27  8:20 [dpdk-dev] [PATCH 0/2] ethdev: make rte flow API thread safe Suanming Mou
2020-09-27  8:20 ` [dpdk-dev] [PATCH 1/2] eal/windows: add pthread mutex lock Suanming Mou
2020-09-27 15:56   ` Dmitry Kozlyuk
2020-09-28  2:30     ` Suanming Mou
2020-09-27  8:20 ` [dpdk-dev] [PATCH 2/2] ethdev: make rte flow API thread safe Suanming Mou
2020-09-30 10:56   ` Ori Kam
2020-10-04 23:44     ` Suanming Mou
2020-10-04 23:48 ` [dpdk-dev] [PATCH v2 0/2] ethdev: make rte_flow " Suanming Mou
2020-10-04 23:48   ` [dpdk-dev] [PATCH v2 1/2] eal/windows: add pthread mutex lock Suanming Mou
2020-10-04 23:48   ` [dpdk-dev] [PATCH v2 2/2] ethdev: make rte_flow API thread safe Suanming Mou
2020-10-05 11:28     ` Ori Kam
2020-10-06 23:18       ` Ajit Khaparde
2020-10-07  0:50         ` Suanming Mou
2020-10-07  6:33           ` Ori Kam
2020-10-07 14:17 ` [dpdk-dev] [PATCH v3 0/2] " Suanming Mou
2020-10-07 14:17   ` [dpdk-dev] [PATCH v3 1/2] eal/windows: add pthread mutex lock Suanming Mou
2020-10-07 16:53     ` Dmitry Kozlyuk
2020-10-08  2:46       ` Suanming Mou
2020-10-14 10:02         ` Tal Shnaiderman
2020-10-07 14:17   ` [dpdk-dev] [PATCH v3 2/2] ethdev: make rte_flow API thread safe Suanming Mou
2020-10-07 14:42     ` Ajit Khaparde
2020-10-07 16:37       ` Ori Kam
2020-10-07 20:10     ` Matan Azrad
2020-10-08  2:56       ` Suanming Mou
2020-10-09  1:17 ` [dpdk-dev] [PATCH v4 0/2] " Suanming Mou
2020-10-09  1:17   ` [dpdk-dev] [PATCH v4 1/2] eal/windows: add pthread mutex lock Suanming Mou
2020-10-09  9:19     ` Tal Shnaiderman
2020-10-14 16:45     ` Ranjit Menon
2020-10-15  2:15     ` Narcisa Ana Maria Vasile
2020-10-15  2:18       ` Suanming Mou
2020-10-09  1:17   ` [dpdk-dev] [PATCH v4 2/2] ethdev: make rte_flow API thread safe Suanming Mou
2020-10-14 10:19     ` Thomas Monjalon [this message]
2020-10-14 10:41       ` Suanming Mou
2020-10-15  1:07 ` [dpdk-dev] [PATCH v5 0/2] " Suanming Mou
2020-10-15  1:07   ` [dpdk-dev] [PATCH v5 1/2] eal/windows: add pthread mutex lock Suanming Mou
2020-10-15  2:22     ` Narcisa Ana Maria Vasile
2020-10-15  1:07   ` [dpdk-dev] [PATCH v5 2/2] ethdev: make rte_flow API thread safe Suanming Mou
2020-10-15  8:28     ` Thomas Monjalon
2020-10-15  8:52       ` Andrew Rybchenko
2020-10-15 22:43   ` [dpdk-dev] [PATCH v5 0/2] " Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2778778.5oPTP038Qd@thomas \
    --to=thomas@monjalon.net \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=orika@nvidia.com \
    --cc=suanmingm@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.