All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: Suanming Mou <suanmingm@nvidia.com>
Cc: Narcisa Ana Maria Vasile <navasile@linux.microsoft.com>,
	Dmitry Malloy <dmitrym@microsoft.com>,
	Pallavi Kadam <pallavi.kadam@intel.com>,
	dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/2] eal/windows: add pthread mutex lock
Date: Sun, 27 Sep 2020 18:56:57 +0300	[thread overview]
Message-ID: <20200927185657.6bbfdc1b@sovereign> (raw)
In-Reply-To: <1601194817-208834-2-git-send-email-suanmingm@nvidia.com>

Hi Suanming,

There's a remark in patch 2/2 and cover letter:

> 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.

Is this property important? To get the described behavior on Windows, you
should've used CRITICAL_SECTION (preferably wrapped in a struct). Mutexes are
kernel objects on Windows and always require syscalls. Otherwise, if mutexes
are sufficient, see a comment inline.

> Add pthread mutex lock as it is needed for the thread safe rte flow
> functions.
> 
> Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
> ---
>  lib/librte_eal/windows/include/pthread.h | 46 ++++++++++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/lib/librte_eal/windows/include/pthread.h b/lib/librte_eal/windows/include/pthread.h
> index 99013dc..4e2e0b3 100644
> --- a/lib/librte_eal/windows/include/pthread.h
> +++ b/lib/librte_eal/windows/include/pthread.h
> @@ -28,6 +28,10 @@
>  /* defining pthread_attr_t type on Windows since there is no in Microsoft libc*/
>  typedef void *pthread_attr_t;
>  
> +typedef void *pthread_mutexattr_t;
> +
> +typedef HANDLE pthread_mutex_t;
> +
>  typedef SYNCHRONIZATION_BARRIER pthread_barrier_t;
>  
>  #define pthread_barrier_init(barrier, attr, count) \
> @@ -139,6 +143,48 @@
>  	return 0;
>  }
>  
> +static inline int
> +pthread_mutex_init(pthread_mutex_t *mutex,
> +		   __rte_unused pthread_mutexattr_t *attr)
> +{
> +	*mutex = CreateMutex(NULL, FALSE, NULL);
> +	if (*mutex == NULL) {
> +		RTE_LOG_WIN32_ERR("CreateMutex()");
> +		return -1;
> +	}
> +	return 0;
> +}
> +
> +static inline int
> +pthread_mutex_lock(pthread_mutex_t *mutex)
> +{
> +	if (WaitForSingleObject(*mutex, INFINITE) != WAIT_OBJECT_0) {
> +		RTE_LOG_WIN32_ERR("WaitForSingleObject()");
> +		return -1;

A relevant error code must be returned according to POSIX. Searching the
code for pthread_mutex_lock() calls, I can see that hinic PMD checks for
EOWNERDEAD (corresponding to WAIT_OBJECT_ABANDONED in Windows) and failsafe
PMD supplies return value of pthread_mutex_unlock() to strerror(), i.e. it
should be an errno. Same applies to other functions.

> +	}
> +	return 0;
> +}
> +
> +static inline int
> +pthread_mutex_unlock(pthread_mutex_t *mutex)
> +{
> +	if (!ReleaseMutex(*mutex)) {
> +		RTE_LOG_WIN32_ERR("ReleaseMutex()");
> +		return -1;
> +	}
> +	return 0;
> +}
> +
> +static inline int
> +pthread_mutex_destroy(pthread_mutex_t *mutex)
> +{
> +	if (!CloseHandle(*mutex)) {
> +		RTE_LOG_WIN32_ERR("CloseHandle()");
> +		return -1;
> +	}
> +	return 0;
> +}
> +
>  #ifdef __cplusplus
>  }
>  #endif


  reply	other threads:[~2020-09-27 15:57 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 [this message]
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
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=20200927185657.6bbfdc1b@sovereign \
    --to=dmitry.kozliuk@gmail.com \
    --cc=dev@dpdk.org \
    --cc=dmitrym@microsoft.com \
    --cc=navasile@linux.microsoft.com \
    --cc=pallavi.kadam@intel.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.