> > Staged-Ordered-Ring (SORING) provides a SW abstraction for 'ordered' queues > > with multiple processing 'stages'. > > It is based on conventional DPDK rte_ring, re-uses many of its concepts, > > and even substantial part of its code. > > It can be viewed as an 'extension' of rte_ring functionality. > > In particular, main SORING properties: > > - circular ring buffer with fixed size objects > > - producer, consumer plus multiple processing stages in the middle. > > - allows to split objects processing into multiple stages. > > - objects remain in the same ring while moving from one stage to the other, > > initial order is preserved, no extra copying needed. > > - preserves the ingress order of objects within the queue across multiple > > stages, i.e.: > > at the same stage multiple threads can process objects from the ring in > > any order, but for the next stage objects will always appear in the > > original order. > > - each stage (and producer/consumer) can be served by single and/or > > multiple threads. > > - number of stages, size and number of objects in the ring are > > configurable at ring initialization time. > > > > Data-path API provides four main operations: > > - enqueue/dequeue works in the same manner as for conventional rte_ring, > > all rte_ring synchronization types are supported. > > - acquire/release - for each stage there is an acquire (start) and > > release (finish) operation. > > after some objects are 'acquired' - given thread can safely assume that > > it has exclusive possession of these objects till 'release' for them is > > invoked. > > Note that right now user has to release exactly the same number of > > objects that was acquired before. > > After 'release', objects can be 'acquired' by next stage and/or dequeued > > by the consumer (in case of last stage). > > > > Expected use-case: applications that uses pipeline model > > (probably with multiple stages) for packet processing, when preserving > > incoming packet order is important. I.E.: IPsec processing, etc. > > > > How does SORING related to Eventdev?
So far there is no direct relation. Though yes, DPDK eventdev framework also provides ‘ordered’ queue ability (along with other modes). Again, as I mentioned in the cover-letter rte_soring uses similar concept as OPDL eventdev implementation. One of the main aims with rte_soring was to introduce sort of extension to rte_ring, while keeping its API and implementation as lightweight and generic as possible. So it could be consumed by various apps that do use pipeline model, but for whatever reason do not use (/plan to use) eventdev framework. > Would it be feasible to reshape this into a SW event device? I guess an opposite approach might work better - i.e. make some SW-based eventdev Implementation to use rte_soring internally. Though I didn't try to do that so far.
