From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 05CCBA0C3F; Thu, 15 Apr 2021 22:05:00 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D4B74162468; Thu, 15 Apr 2021 22:05:00 +0200 (CEST) Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by mails.dpdk.org (Postfix) with ESMTP id ED422162466 for ; Thu, 15 Apr 2021 22:04:59 +0200 (CEST) Received: by mail-pj1-f51.google.com with SMTP id u11so9037950pjr.0 for ; Thu, 15 Apr 2021 13:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=DaqCt5M7WG6cHGsOVyGSCtQtsk5uBJ9JI3EHZKV9l9w=; b=jBR9JZhnYvQZICpUL0Zxtm6hTJCcPH+9cHg4CEH/bF4qHhT4H49OhA677xlymvkMS5 aFzqf0ZCqBe/xRUUMT+Icyg/Tx+QbZAP3E1kAwVLLbYl02cdsElIjUPPeyauQKmv8Zwu B96Lm6KJS9rSISNZwS1zBYSNzDwuFU5ihcfUea9w/wWQRPReeZkKvgLRXkrUHXxU4H1u 6WfN54SZHI4NgHtP+Y1pRx5J+PQAhoryXlpfeWN6Ocr90W4Cq3Bv4JjXY1ffQLz/+NwO AL//5AlTbTkNIajpKkuTbhL/2L8SNu6nhTckczQh4kdMOMpW1yOSUN72sUFC+YDqeB/D +VKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=DaqCt5M7WG6cHGsOVyGSCtQtsk5uBJ9JI3EHZKV9l9w=; b=hymSsQGvqa4TXmPop25JWv6kN49kBMzLJdzVN//JpHIKRqfnfEZU1oTmtGvPNV40IJ +Tuv9NtC7uCrynXLLbkeIKYr0zQ+Z9dVECWlr3TwkCP2SeLtKgjnvGZFx0hPPHnQ0IGA jDT9BOdWGOBE5w3NLDpZ/sMBOfmsqj/Wcg96cTtcP+jNSQrcMNuE0oM+oZF21SXTf8TO 6dhUtoowCuGlqTCIOuK+DnJcxepMb3bON3B7JUHTwHYKiIfaLwjuEoCAezh29Ikdd0He gy1C4C5Shmx46bFyMoXTNYVr+GIbb1H7b4bd20crRCtsHooC5jeIcMERrwDKi25JIyzF h4Bw== X-Gm-Message-State: AOAM532JTrrufaPMm/9HlyT08t4W8dKl94jS4lHBc2rluGbqt46nd2dp BREDR6vL1acc50Nf0ih0hZql0g== X-Google-Smtp-Source: ABdhPJxpWAuJhmQS7QKzTyJbQ5Rxk8wtim438hx5FW0Dt+UiEVD+23SM0WmEqRXjhRkPOs/VJyBaWg== X-Received: by 2002:a17:902:e289:b029:eb:29e7:beda with SMTP id o9-20020a170902e289b02900eb29e7bedamr5559473plc.78.1618517099079; Thu, 15 Apr 2021 13:04:59 -0700 (PDT) Received: from hermes.local (76-14-218-44.or.wavecable.com. [76.14.218.44]) by smtp.gmail.com with ESMTPSA id d5sm3244460pgj.36.2021.04.15.13.04.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Apr 2021 13:04:58 -0700 (PDT) Date: Thu, 15 Apr 2021 13:04:50 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: Suanming Mou , Ori Kam , Andrew Rybchenko , NBU-Contact-Thomas Monjalon , "dev@dpdk.org" , Matan Azrad , Shahaf Shuler , Ajit Khaparde , Somnath Kotur Message-ID: <20210415130450.2b6ada64@hermes.local> In-Reply-To: <14c8924a-24cc-b857-2a5c-260b0fcc02ef@intel.com> References: <20210315192722.35490-1-stephen@networkplumber.org> <20210315192722.35490-2-stephen@networkplumber.org> <7106da73-95a1-30ae-f949-87ecca05b24d@intel.com> <14c8924a-24cc-b857-2a5c-260b0fcc02ef@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: make flow API primary/secondary process safe X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" On Thu, 15 Apr 2021 08:42:39 +0100 Ferruh Yigit wrote: > > (If I understand correctly, mlx PMD level now should support multi-proc= ess, 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. > > =20 >=20 > I am also not quite sure how PMDs that doesn't require mutex at all, (mlx= 5,=20 > bnxt, sfc) behave on multi process. Is calling flow APIs from both=20 > primary/secondary safe? >=20 > >> > >> > >> Stephen, > >> Are you aware of any downside setting 'PTHREAD_PROCESS_SHARED' attribu= te > >> 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 synch= ro=E2=80=90 nization only between threads of the same process). This all= ows the kernel to make some additional performance optimizations.