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

Matan Azrad matan at mellanox.com
Thu Jan 18 21:21:34 CET 2018


Hi Neil.

From: Neil Horman, Thursday, January 18, 2018 8:42 PM

<snip>
> > > But thats not all.  The determination of success or failure in
> > > claiming ownership is largely dependent on the behavior of other
> > > threads actions, not a function of the state of the system at the moment
> ownership is requested.
> > > That is to say, if you have N threads, and they all create ownership
> > > objects identified as X, x+1, X+2...X+N, only the thread with id X+N
> > > will be able to claim ownership of any port, because they all will
> > > have incremented the shared nex_id variable.
> >
> > Why? Each one will get its owner id according to some order(The critical
> section is protected by spinlock).
> >
> Yes, and thats my issue here, the ordering.  Perhaps my issue is one of
> perception.  When I consider an ownership library, what I really think about is
> mutual exclusion (i.e. guaranteing that only one entity is capable of access to
> a resource at any one time).  This semantics of this library don't really
> conform to any semantics that you usually see with other mutual exclusion
> mechanisms.  That is to say a spinlock or a mutex succedes locking if its prior
> state is unlocked.  This library succeeds aqusition of the resource it protects if
> and only if allocation of ownership records occurs in a particular order relative
> to one another.  That just seems odd to me.  What advantage do these new
> semantics have over more traditional established semantics?
> 
> 
> > >  Determination of ownership by the programmer will have to be done
> > > via debugging, and errors will likely be transient dependent on the
> > > order in which threads execute (subject to scheduling jitter).
> > >
> > Yes.
> >
> But why put yourself through that pain?  Traditional semantics are far simpler
> to comprehend, with and without a debugger.
> 

Looks like I missed you, sorry:
Please describe next:

1. What exactly do you want to improve?(in details)
2. Which API specifically do you want to change(\ part of code)?
3. What is the missing in current code(you can answer it in V3 I sent if you want) which should be fixed?


<snip> sorry for that, I think it is not relevant continue discussion if we are not fully understand each other. So let's start from the beginning "with good order :)" by answering the above questions.




More information about the dev mailing list