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

["Morten Brørup" <mb@smartsharesystems.com>]

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.
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().