From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 7A02BDE0 for ; Wed, 10 Dec 2014 17:17:27 +0100 (CET) Received: from nat-pool-rdu-t.redhat.com ([66.187.233.202] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Xyjwk-0004jK-1v; Wed, 10 Dec 2014 11:17:10 -0500 Date: Wed, 10 Dec 2014 11:16:46 -0500 From: Neil Horman To: Bruce Richardson Message-ID: <20141210161646.GE17040@localhost.localdomain> References: <1404818184-29388-1-git-send-email-danielx.t.mrzyglod@intel.com> <20141208144545.GD3237@localhost.localdomain> <20141210144745.GC17040@localhost.localdomain> <20141210145455.GC1632@bricha3-MOBL3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141210145455.GC1632@bricha3-MOBL3> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 16:17:28 -0000 On Wed, Dec 10, 2014 at 02:54:56PM +0000, Bruce Richardson wrote: > On Wed, Dec 10, 2014 at 09:47:45AM -0500, Neil Horman wrote: > > On Wed, Dec 10, 2014 at 08:18:36AM +0000, Wodkowski, PawelX wrote: > > > > Though, that said, doesn't it seem to anyone else like serialization of enqueue > > > > to a port should be the responsibility of the library, not the application? > > > > > > > > Neil > > > > > > From my knowledge it is an application responsibility to serialize access to > > > queue on particular port. > > > > > I understand thats the way it currently is, I'm advocating for the fact that it > > should not be. > > Neil > > > It could be done, but I think we'd need to add a new API (or new parameter to > existing API) to do so, as the cost of adding the locks would be severe, even in > the uncontented case. > This is why it hasn't been done up till now, obviously enough. In general, where > we don't provide performant multi-thread safe APIs, we generally don't try and > provide versions with locks, we just document the limitation and then leave it > up to the app to determine how best to handle things. > 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. I agree that, in the single process case, there might be a slight performance loss (though I contend it wouldn't be greatly significant). That said, I would argue that the right approach is to do the locking internally to the DPDK, then provide a configuration point which toggles the spinlock defintions to either do proper locking, or just reduce to empty definitions, the same way the Linux and BSD kernels do in the uniprocessor case. That way applications never have to worry about internal locking, and you can still build for the optimal case when you need to. Neil > /Bruce >