From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com
 [209.85.192.169]) by dpdk.org (Postfix) with ESMTP id 279BC6A87
 for <dev@dpdk.org>; Thu, 11 Dec 2014 00:38:48 +0100 (CET)
Received: by mail-pd0-f169.google.com with SMTP id z10so3781075pdj.0
 for <dev@dpdk.org>; Wed, 10 Dec 2014 15:38:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-type:content-transfer-encoding;
 bh=iQhla/p3yfDHFuw3A68708Ln+fB3BvD7Dnt+QUFEPuA=;
 b=dazlaIJ1JITb9OGIms0/V1kVMCZFjYS+iQgzbhSaG1XrhU/x0baBXFHi2OkXZfvGtG
 wV/MWaUEnKwDTWFAq7bkCmLEmkk1t4VexfUH3JidWV3PddUb4UszKIKBCYsrgh38AuPX
 9cL2DiSxECzJBrRDNE9EKUUpFrKJW+UZ4+Ur1tJsmOaHB1RBAE5Hmu7dgufv8KxU6S8b
 fgXt95RZTV38MdyqNqONTF7+XphUCuMk2oGgG7OrRf8j6qf7Fe4g0DqH6mskgYIw4scx
 y+Dz49FIpx96IQtcgHHH//YtH5NjyaP1v2fJUBRhZHy+YXNaZVYyrBXwb8U9h628oxDg
 2UOA==
X-Gm-Message-State: ALoCoQlYI2mYH0e058CbarBg1Ekijs4ypUf/WgDgtwmODER0cMoMnelEZJQRhu6tdkeHlfWnzd4z
X-Received: by 10.68.88.3 with SMTP id bc3mr11810832pbb.150.1418254727286;
 Wed, 10 Dec 2014 15:38:47 -0800 (PST)
Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net.
 [50.53.82.155])
 by mx.google.com with ESMTPSA id ri3sm5194727pdb.58.2014.12.10.15.38.44
 for <multiple recipients>
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 10 Dec 2014 15:38:46 -0800 (PST)
Date: Wed, 10 Dec 2014 15:38:37 -0800
From: Stephen Hemminger <stephen@networkplumber.org>
To: Neil Horman <nhorman@tuxdriver.com>
Message-ID: <20141210153837.1f30eed8@urahara>
In-Reply-To: <20141210161646.GE17040@localhost.localdomain>
References: <1404818184-29388-1-git-send-email-danielx.t.mrzyglod@intel.com>
 <20141208144545.GD3237@localhost.localdomain>
 <F6F2A6264E145F47A18AB6DF8E87425D12B6C944@IRSMSX106.ger.corp.intel.com>
 <20141210144745.GC17040@localhost.localdomain>
 <20141210145455.GC1632@bricha3-MOBL3>
 <20141210161646.GE17040@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Added Spinlock to l3fwd-vf example to prevent race
 conditioning
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Dec 2014 23:38:48 -0000

On Wed, 10 Dec 2014 11:16:46 -0500
Neil Horman <nhorman@tuxdriver.com> wrote:

> This really seems like a false savings to me.  If an application intends to use
> multiple processes (which by all rights it seems like the use case that the dpdk
> is mostly designed for) then you need locking one way or another, and you've
> just made application coding harder, because the application now needs to know
> which functions might have internal critical sections that they need to provide
> locking for.

The DPDK is not Linux.
See the examples of how to route without using locks by doing asymmetric multiprocessing.
I.e queues are only serviced by one CPU.

The cost of a locked operation (even uncontended) is often enough to drop
packet performance by several million PPS.