From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com
 [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 5434B7D52
 for <dev@dpdk.org>; Fri,  8 Dec 2017 12:35:20 +0100 (CET)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.nyi.internal (Postfix) with ESMTP id CACDB20CF3;
 Fri,  8 Dec 2017 06:35:19 -0500 (EST)
Received: from frontend2 ([10.202.2.161])
 by compute1.internal (MEProxy); Fri, 08 Dec 2017 06:35:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 cc:content-transfer-encoding:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-sender
 :x-me-sender:x-sasl-enc; s=mesmtp; bh=fRZIU9yIcSUIIWQvaONoUQLLX2
 vt3zT4C8nO6tsfP6s=; b=RuZqEejxuYrGEcINOUO63UQT4SW/1O8kFsa8rpTljL
 KuyMa/3/33RFLNCiFX0H0//yJG29bhxikxLeJKzBVzm6Dfa+qWz6Onop8ajjNjIF
 OzdisPctNbek9Sv8/d0lsQt2V9NTjvQVAbhjSy7Thp54pOa8CmzrdKeK+B9k9IXd
 8=
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-sender:x-me-sender:x-sasl-enc; s=fm1; bh=fRZIU9
 yIcSUIIWQvaONoUQLLX2vt3zT4C8nO6tsfP6s=; b=RSY9u4irC+XqUPrJbXAOSV
 uzQ/7rQLwGpa69GKGt9C47SLHsC1hNaQf/Wk/Zr4WvmGLgl0i3KIAerZ0SbrtRE5
 pR3uXR+5Dys6y4EfuxNGhwn6TUqaKoI2tMVag9XJGjhFp/PkCHDHYM+5Ko8AG1tZ
 SqhMxM8VihmuI1TQyS5ULhJB+J82dAaXccrTtPh8fc9xmWjJYTReR2x6nW8ZxtwA
 3wc2O0Y3Rw1kQPmI5K4LQXsA26wzl16GnicEoN5ZKmA8Dd/9T2KIAhy5e4TUl8YA
 3HfUIOY0bAiLD5PqncLbON2tuhWNNrhiH8T7Lr0/2pvT5T0KdR3kbQJ+tytQaHZg
 ==
X-ME-Sender: <xms:93gqWqxsAwJoCEWjQ49F4k5XThl8DWAb_m_zyKoKzJDFA6WGy8wyOA>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id 7882024136;
 Fri,  8 Dec 2017 06:35:19 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Matan Azrad <matan@mellanox.com>, Neil Horman <nhorman@tuxdriver.com>,
 "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 =?ISO-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com>, "Wu,
 Jingjing" <jingjing.wu@intel.com>, dev@dpdk.org
Date: Fri, 08 Dec 2017 12:35:18 +0100
Message-ID: <5212147.QN8ImyqEg2@xps>
In-Reply-To: <20171205100542.GA7492@bricha3-MOBL3.ger.corp.intel.com>
References: <20171130123611.GA20914@hmswarspite.think-freely.org>
 <HE1PR0502MB3659563360991F8F0C650D0DD23D0@HE1PR0502MB3659.eurprd05.prod.outlook.com>
 <20171205100542.GA7492@bricha3-MOBL3.ger.corp.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <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: Fri, 08 Dec 2017 11:35:20 -0000

05/12/2017 11:05, Bruce Richardson:
> > I think you suggest to make all the ethdev configuration race safe, it
> > is behind to this thread.  Current ethdev implementation leave the
> > race management to applications, so port ownership as any other port
> > configurations should be designed in the same method.
> 
> One key difference, though, being that port ownership itself could be
> used to manage the thread-safety of the ethdev configuration. It's also
> a little different from other APIs in that I find it hard to come up
> with a scenario where it would be very useful to an application without
> also having some form of locking present in it. For other config/control
> APIs we can have the control plane APIs work without locks e.g. by
> having a single designated thread/process manage all configuration
> updates. However, as Neil points out, in such a scenario, the ownership
> concept doesn't provide any additional benefit so can be skipped
> completely. I'd view it a bit like the reference counting of mbufs -
> we can provide a lockless/non-atomic version, but for just about every
> real use-case, you want the atomic version.

I think we need to clearly describe what is the tread-safety policy
in DPDK (especially in ethdev as a first example).
Let's start with obvious things:

	1/ A queue is not protected for races with multiple Rx or Tx
			- no planned change because of performance purpose
	2/ The list of devices is racy
			- to be fixed with atomics
	3/ The configuration of different devices is thread-safe
			- the configurations are different per-device
	4/ The configuration of a given device is racy
			- can be managed by the owner of the device
	5/ The device ownership is racy
			- to be fixed with atomics

What am I missing?

I am also wondering whether the device ownership can be a separate
library used in several device class interfaces?