Re: [PATCH 2/5] ethdev: add port ownership

[Thomas Monjalon <thomas@monjalon.net>]

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?