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

[Thomas Monjalon]

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?