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 C44599B6B for ; Fri, 8 Dec 2017 13:32:38 +0100 (CET) Received: from cpe-2606-a000-111b-423c-e874-da8e-c543-d863.dyn6.twc.com ([2606:a000:111b:423c:e874:da8e:c543:d863] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1eNHpA-0000Vg-KL; Fri, 08 Dec 2017 07:32:26 -0500 Date: Fri, 8 Dec 2017 07:31:42 -0500 From: Neil Horman To: Thomas Monjalon Cc: Bruce Richardson , Matan Azrad , "Ananyev, Konstantin" , =?iso-8859-1?Q?Ga=EBtan?= Rivet , "Wu, Jingjing" , dev@dpdk.org Message-ID: <20171208123142.GA6955@hmswarspite.think-freely.org> References: <20171130123611.GA20914@hmswarspite.think-freely.org> <20171205100542.GA7492@bricha3-MOBL3.ger.corp.intel.com> <5212147.QN8ImyqEg2@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5212147.QN8ImyqEg2@xps> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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: Fri, 08 Dec 2017 12:32:39 -0000 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? 2) Is device configuration racy with device addition/removal? That is to say, can one thread remove a device while another configures it. 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? >