From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: Added Spinlock to l3fwd-vf example to prevent race conditioning Date: Wed, 10 Dec 2014 15:38:37 -0800 Message-ID: <20141210153837.1f30eed8@urahara> References: <1404818184-29388-1-git-send-email-danielx.t.mrzyglod@intel.com> <20141208144545.GD3237@localhost.localdomain> <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-VfR2kkLFssw@public.gmane.org" To: Neil Horman Return-path: In-Reply-To: <20141210161646.GE17040-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" On Wed, 10 Dec 2014 11:16:46 -0500 Neil Horman 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.