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 C7EC5A04AA; Tue, 8 Sep 2020 17:04:03 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8867D4C99; Tue, 8 Sep 2020 17:04:02 +0200 (CEST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id B42C4255 for ; Tue, 8 Sep 2020 17:04:01 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 9A590580499; Tue, 8 Sep 2020 11:03:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 08 Sep 2020 11:03:58 -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= 4FE/unHLanjDvH7JLhzDlGXe1sXQHO+0eFb8VDFbH6Q=; b=Y9vOdoR8TBAELEYx ph6Kxysao2fUSZAGnxut/oIq+BB2ZZnb1VChUXxTCvQOKcFkliTbVVT+yY+G4q7z 4kcucikJAFBV13q9Au3F9UmlvIIXM0qLOpGTkKruESPU4hr9B493Z7Oc2vnvEoCt JGIbePasnA43QLBCNMKfs3Q8euf8OOecvp+wMQPu04/Cb9etvMVhjNaQ+/EqHH4C WU4r+sQqskUobmX8zJU9tqvBeQh6VnpS9aHRlz5QN9UUF4pXEXzsowcARDl8NYZR g7laU+ebnhhLoiC1HP2C5kdVRgTKtR9iSnQrtiG1FuX+fsBm9Z9Ozfez05Ld04Pb yE1WgQ== 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=fm3; bh=4FE/unHLanjDvH7JLhzDlGXe1sXQHO+0eFb8VDFbH 6Q=; b=RdFfPTg99D/ye6+MB3HD4sTFt+sPKiyeV+6eJOpKV+FusDFX+nmpQ1djV Ws5eJD8jKdsZSURLCv2qAmjm16pxtabcir/L67QwfECien1/RJbOUs0Vk4nMkI8r o4lwOZi3cCaaQQeOADV82nGvwETUsiaDmwGyAyKx+XglvBxmRLKVF5VfCx9UCbNV i+iTQc+J6uEosQSR+Pl9gbGfrXUt2UI+odtUJ4cbjrnUiqyANMa2HG98RlfoVzUY Teuxm4+/1jVc7dYkWLz4+T95bbrv1pNKmTYxespCCCKXAGSxpvPAThNuC5Xbp/u8 HMCfjhQNeZxaJAaoUoDnuoOD3xJWg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehfedgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 5705E3280060; Tue, 8 Sep 2020 11:03:55 -0400 (EDT) From: Thomas Monjalon To: Suanming Mou , Stephen Hemminger Cc: Ori Kam , Matan Azrad , Shahaf Shuler , Viacheslav Ovsiienko , Ferruh Yigit , Andrew Rybchenko , "dev@dpdk.org" , joyce.kong@arm.com, phil.yang@arm.com, steve.capper@arm.com, honnappa.nagarahalli@arm.com Date: Tue, 08 Sep 2020 17:03:53 +0200 Message-ID: <3402903.UWDKPdykxe@thomas> In-Reply-To: <20200908075208.048bfa02@hermes.lan> References: <1599108782-230624-1-git-send-email-suanmingm@nvidia.com> <20200908075208.048bfa02@hermes.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC] 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" 08/09/2020 16:52, Stephen Hemminger: > On Mon, 7 Sep 2020 02:36:48 +0000 > Suanming Mou wrote: > > > What is the performance impact of this for currently working applications that > > > use a single thread to program flow rules. You are adding a couple of system > > > calls to what was formerly a totally usermode operation. > > Read the source for glibc and see what pthread_mutex does What would be the best lock for rte_flow? We have spin lock, ticket lock, MCS lock (and rwlock) in DPDK. > > If I understand correctly, in the non-contended single thread case, pthread mutex lock should not go to the kernel space. > > I also wrote a small application with pthread mutex, and strace shows no system call was introduced. > > > > Another simple testing code below is to check the cycles cost difference in every round between pthread mutex and spin_lock. > > Micro benchmarks of locking is hard to see.