From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bruce.richardson@intel.com>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id F30686A8B
 for <dev@dpdk.org>; Wed, 10 Dec 2014 15:54:59 +0100 (CET)
Received: from orsmga003.jf.intel.com ([10.7.209.27])
 by orsmga103.jf.intel.com with ESMTP; 10 Dec 2014 06:53:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="496673335"
Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.31])
 by orsmga003.jf.intel.com with SMTP; 10 Dec 2014 06:51:10 -0800
Received: by  (sSMTP sendmail emulation); Wed, 10 Dec 2014 14:54:56 +0025
Date: Wed, 10 Dec 2014 14:54:56 +0000
From: Bruce Richardson <bruce.richardson@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
Message-ID: <20141210145455.GC1632@bricha3-MOBL3>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20141210144745.GC17040@localhost.localdomain>
Organization: Intel Shannon Ltd.
User-Agent: Mutt/1.5.23 (2014-03-12)
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 14:55:00 -0000

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.

/Bruce