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

[Konstantin Ananyev]

> I have been following this interesting discussion, and want to clarify:
> 
> For a generic ring, enqueue can fail if the ring doesn't have sufficient free space, and
> dequeue can fail if it doesn't have sufficient objects in queue.
> 
> However, when a ring is used as the backing store for a mempool, enqueue can
> never fail. (Dequeue can still fail if the mempool has been depleted.)
> 
> The reason enqueue into a mempool ring can never fail is:
> On creation of the mempool ring, the objects held by the mempool (e.g. mbufs) are
> allocated in memory and enqueued into the ring. If the mempool ring has size SIZE,
> then SIZE objects are allocated in memory and enqueued into the mempool ring.
> So, since only SIZE objects exist in the whole world, and the mempool ring has size
> SIZE, enqueue of those objects into the mempool ring cannot fail, and the mempool
> "put" API reflects this.
> 
> Note that this is a requirement for the mempool API, not the ring API.
> So, if the ring API doesn't provide this guarantee (that if only SIZE objects exist,
> enqueue cannot fail), then this guarantee could be implemented in the mempool
> library where it interfaces to the ring "enqueue" API (instead of having the ring API
> provide this guarantee).
> 
> However, other libraries or applications might assume the same guarantee for a ring
> when no more than SIZE objects exist. (I don't know!) If this is the case, then it is a
> ring API requirement, not just a mempool API requirement.

Yep, there could be other libs (both DPDK and third-party) that rely on that.
That's why I think we need to preserve existing behavior of the public ring API.  
Providing some extra (fast) version of API is possible, though I am not big fan
of that idea: it will complicate and increase existing code quite a bit, while
I don't think the gain would be that huge.
But again - I think that new API shall be subject of a separate patch-set and discussion.
As first thing we do need a fix or existing one.
Thank you for great summary.  
Konstantin

> One possible solution to this could be offering two ring enqueue APIs, a "fast" API
> without the guarantee and a "safe" API with the guarantee.
> Somewhat like the iteration macros for linked lists: foreach() and foreach_safe().