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