From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 3E98A1B2A4 for ; Thu, 21 Dec 2017 18:06:50 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9115120BDE; Thu, 21 Dec 2017 12:06:49 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 21 Dec 2017 12:06:49 -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=uXnQaoQ4+iFQbisqPrUnM9HgSZ uOGazXAShbyH2FOGw=; b=FbIX9c/dktFeV5fqpSYiPLiwQ9nFWhBs514U/1krQY 5yhZy6350xM0HfV5Y54PuetHjFz3vOAsvR2lNvPFa/K1+eWqf2fqqOuOefNZ+j/2 eUXzkniBECgBwzRC00nAbb6lVoVP2p1B5Ezz5/tdpeNkCiTVcxPrx5yusdBsAEJG Q= 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=uXnQao Q4+iFQbisqPrUnM9HgSZuOGazXAShbyH2FOGw=; b=eU83BjFo7MWzdOpRS169R6 4I2HAleQacby91lOVbc3uSDicdxsmbtRoDnN6n7B9oFQBW8mHPJCbxUq7U4MxZbH yldJmUTkg94LPkMPNDVJ+NtO+u2QZy+xbE58LdZfaK0ndsD21kFuP69XA7R1OqH6 7zXNbC4V//8JA7O5XnIkhTuhpn0p5keNO/BivarnoE0/bQ+LalXqGVuT0Ye9ViTq YaCKub8R5Uq5Y1GqvNqBUBQZCILvOfsf3itrXs9hKMy9UbUGfOiTNZ3B949p/+gC fbEH37kn6FgL0OyskJZ7NYadtUMmQPTVqWiXWfSoy3FGDe7G1xy1qSaJ746/a7Sw == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2540F7E53A; Thu, 21 Dec 2017 12:06:49 -0500 (EST) From: Thomas Monjalon To: Neil Horman Cc: dev@dpdk.org, Bruce Richardson , Matan Azrad , "Ananyev, Konstantin" , =?ISO-8859-1?Q?Ga=EBtan?= Rivet , "Wu, Jingjing" Date: Thu, 21 Dec 2017 18:06:48 +0100 Message-ID: <1567916.dnd6Z652YM@xps> In-Reply-To: <20171208123142.GA6955@hmswarspite.think-freely.org> References: <20171130123611.GA20914@hmswarspite.think-freely.org> <5212147.QN8ImyqEg2@xps> <20171208123142.GA6955@hmswarspite.think-freely.org> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 17:06:50 -0000 08/12/2017 13:31, Neil Horman: > On Fri, Dec 08, 2017 at 12:35:18PM +0100, Thomas Monjalon wrote: > > 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? > > > There is fan out to consider here: > > 1) Is device configuration racy with ownership? That is to say, can I change > ownership of a device safely while another thread that currently owns it > modifies its configuration? If an entity steals ownership to another one, either it is agreed earlier, or it is done by a central authority. When it is acked that ownership can be moved, there should not be any configuration in progress. So it is more a communication issue than a race. > 2) Is device configuration racy with device addition/removal? That is to say, > can one thread remove a device while another configures it. I think it is the same as two threads configuring the same device (item 4/ above). It can be managed with port ownership. > There are probably many subsystem interactions that need to be addressed here. > > Neil > > > I am also wondering whether the device ownership can be a separate > > library used in several device class interfaces?