DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: Suanming Mou <suanmingm@nvidia.com>, Ori Kam <orika@nvidia.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
	"dev@dpdk.org" <dev@dpdk.org>, Matan Azrad <matan@nvidia.com>,
	Shahaf Shuler <shahafs@nvidia.com>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>,
	Somnath Kotur <somnath.kotur@broadcom.com>
Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: make flow API primary/secondary process safe
Date: Thu, 15 Apr 2021 13:04:50 -0700	[thread overview]
Message-ID: <20210415130450.2b6ada64@hermes.local> (raw)
In-Reply-To: <14c8924a-24cc-b857-2a5c-260b0fcc02ef@intel.com>

On Thu, 15 Apr 2021 08:42:39 +0100
Ferruh Yigit <ferruh.yigit@intel.com> wrote:

> > (If I understand correctly, mlx PMD level now should support multi-process, but better to have the confirmation from maintainers with much deeper level).
> > I assume this patch solves the posix mutex for multi-process only, hard to say the flow API primary/secondary process safe after that patch.
> >   
> 
> I am also not quite sure how PMDs that doesn't require mutex at all, (mlx5, 
> bnxt, sfc) behave on multi process. Is calling flow APIs from both 
> primary/secondary safe?
> 
> >>
> >>
> >> Stephen,
> >> Are you aware of any downside setting 'PTHREAD_PROCESS_SHARED' attribute
> >> to the
> >> mutex? Any possible performance implications?
> >>

Only impacts the contended case.

Setting the PROCESS_SHARED turns the mutex causes the mutex to behave
differently when cmxchg fails. Internally pthread_mutex_lock will
call futex if it has to wait and the SHARED flag impacts whether
FUTEX_PRIVATE_FLAG is set.

       FUTEX_PRIVATE_FLAG (since Linux 2.6.22)
              This option bit can be employed with all futex  operations.   It
              tells  the  kernel  that  the  futex  is process-private and not
              shared with another process (i.e., it is being used for synchro‐
              nization only between threads of the same process).  This allows
              the kernel to make some additional performance optimizations.

  reply	other threads:[~2021-04-15 20:05 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 19:27 [dpdk-dev] [PATCH 0/2] Mark shared pthread mutex Stephen Hemminger
2021-03-15 19:27 ` [dpdk-dev] [PATCH 1/2] ethdev: make flow API primary/secondary process safe Stephen Hemminger
2021-03-16 23:48   ` Suanming Mou
2021-03-17  0:13     ` Stephen Hemminger
2021-03-17  0:32       ` Suanming Mou
2021-04-14 13:06     ` Ferruh Yigit
2021-04-15  2:55       ` Suanming Mou
2021-04-15  3:17         ` Stephen Hemminger
2021-04-15  7:42         ` Ferruh Yigit
2021-04-15 20:04           ` Stephen Hemminger [this message]
2021-04-16  0:57           ` Suanming Mou
2021-04-16  3:19           ` Ajit Khaparde
2021-04-16  1:41       ` fengchengwen
2021-04-16  8:12         ` Ferruh Yigit
2021-04-16  8:18   ` Ferruh Yigit
2021-04-19 17:14   ` Thomas Monjalon
2021-04-19 17:45     ` Stephen Hemminger
2021-04-19 18:09       ` Thomas Monjalon
2021-06-08  8:07   ` Andrew Rybchenko
2021-03-15 19:27 ` [dpdk-dev] [PATCH 2/2] net/failsafe: fix primary/secondary mutex Stephen Hemminger
2021-04-14 13:10   ` Ferruh Yigit
2021-04-16  8:19     ` Ferruh Yigit
2021-04-19 17:08   ` Thomas Monjalon
2021-06-08  8:00     ` Andrew Rybchenko
2021-06-08 15:42       ` Stephen Hemminger
2021-06-08 15:55         ` Andrew Rybchenko
2021-06-08 20:48           ` Stephen Hemminger
2021-06-09 10:04             ` Andrew Rybchenko
2021-06-14 14:43               ` Gaëtan Rivet
2022-10-17 10:40                 ` [External] : " Madhuker Mythri
2021-03-15 19:45 ` [dpdk-dev] [PATCH 0/2] Mark shared pthread mutex Stephen Hemminger
2021-03-16 16:28 ` Stephen Hemminger
2021-04-16  8:25   ` Ferruh Yigit

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=20210415130450.2b6ada64@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=matan@nvidia.com \
    --cc=orika@nvidia.com \
    --cc=shahafs@nvidia.com \
    --cc=somnath.kotur@broadcom.com \
    --cc=suanmingm@nvidia.com \
    --cc=thomas@monjalon.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).