RE: [PATCH 1/1] ring: safe partial ordering for head/tail update

[Konstantin Ananyev <konstantin.ananyev@huawei.com>]

> > > Sure, I am talking about MT scenario.
> > > I think I already provided an example: DPDK mempool library (see below).
> > > In brief, It works like that:
> > > At init it allocates ring of N memory buffers and ring big enough to hold all of
> them.
> >
> > Sorry, I meant to say: "it allocates N memory buffers and ring big enough to hold
> all of them".
> >
> > > Then it enqueues all allocated memory buffers into the ring.
> > > mempool_get - retrieves (dequeues) buffers from the ring.
> > > mempool_put - puts them back (enqueues) to the ring
> > > get() might fail (ENOMEM), while put is expected to always succeed.
> But how does the thread which calls mempool_put() get hold of the memory buffers
> that
> were obtained using mempool_get() by some other thread? Or this is not the
> scenario you
> are worrying about?
> Is it rather that multiple threads independently call mempool_get() and then
> mempool_put()
> on their own buffers? And you are worried that a thread will fail to return
> (mempool_put) a
> buffer that it earlier allocated (mempool_get)? We could create a litmus test for
> that.

Both scenarios are possible.
For Run-To-Completion model each thread usually does: allocate/use/free group of mbufs.
For pipleline model one thread can allocate bunch of mbufs, then pass them to other 
thread (via another ring for example) for further processing and then releasing.