[dpdk-dev] [PATCH 2/5] ethdev: add port ownership

Neil Horman nhorman at tuxdriver.com
Thu Dec 21 18:43:04 CET 2017


On Thu, Dec 21, 2017 at 06:06:48PM +0100, Thomas Monjalon wrote:
> 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.
> 
But if thats the case (specifically that mutual exclusion between port ownership
and configuration is an exercize left to an application developer), then port
ownership itself is largely meaningless within the dpdk, because the notion of
who owns the port needs to be codified within the application anyway.


> > 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.
> 
Only if you assert that application is required to have the owning port be
responsible for the ports deletion, which we can say, but that leads to the
issue above again.


> > 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?
> 
> 
> 


More information about the dev mailing list