From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH 2/5] ethdev: add port ownership Date: Fri, 08 Dec 2017 12:35:18 +0100 Message-ID: <5212147.QN8ImyqEg2@xps> References: <20171130123611.GA20914@hmswarspite.think-freely.org> <20171205100542.GA7492@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Matan Azrad , Neil Horman , "Ananyev, Konstantin" , =?ISO-8859-1?Q?Ga=EBtan?= Rivet , "Wu, Jingjing" , dev@dpdk.org To: Bruce Richardson Return-path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 5434B7D52 for ; Fri, 8 Dec 2017 12:35:20 +0100 (CET) In-Reply-To: <20171205100542.GA7492@bricha3-MOBL3.ger.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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?