On Fri, Jan 19, 2018 at 09:30:17AM +0000, Bruce Richardson wrote:
> On Fri, Jan 19, 2018 at 07:14:17AM +0000, Matan Azrad wrote:
> >
> > Hi Neil
> > From: Neil Horman, Friday, January 19, 2018 3:41 AM
> > > On Thu, Jan 18, 2018 at 08:21:34PM +0000, Matan Azrad wrote:
> > > > Hi Neil.
> > > >
> > > > From: Neil Horman, Thursday, January 18, 2018 8:42 PM
> >
> > <snip>
> > > > 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.
> > >
> > >
> > > Sure, this seems like a reasonable way to level set.
> > >
> > > I mentioned in another thread that perhaps some of my issue here is
> > > perception regarding what is meant by ownership. When I think of an
> > > ownership api I think primarily of mutual exclusion (that is to say,
> > > enforcement of a single execution context having access to a resource at
> > > any
> > > given time. In my mind the simplest form of ownership is a spinlock or a
> > > mutex. A single execution context either does or does not hold the
> > > resource
> > > at any one time. Those contexts that attempt to gain excusive access to
> > > the
> > > resource call an api that (depending on
> > > implementation) either block continued execution of that thread until
> > > exclusive access to the resource can be granted, or returns immediately
> > > with
> > > a success or error indicator to let the caller know if access is granted.
> > >
> > > If I were to codify this port ownership api in pseudo code it would look
> > > something like this:
> > >
> > > struct rte_eth_dev {
> > >
> > > < eth dev bits >
> > > rte_spinlock_t owner_lock;
> > > bool locked;
> > > pid_t owner_pid;
> > > }
> > >
> As an aside, if you ensure that both locked (or "owned", I think in this
> context) and owner_pid are integer values, you can do away with the lock
> and use a compare-and-set to take ownership, by setting both atomically
> if unmodified from the originally read values.
>
This is true, since the lock is release at the end of each API function
(effectively making each API function atomic). Though, a dpdk spinlock is just
a compare_and_set operation with a built in yield()
Neil
>
