On Mon, 4 Sep 2023 15:03:10 +0200 Mattias Rönnblom <mattias.ronnb...@ericsson.com> wrote:
> The purpose of the dispatcher library is to decouple different parts > of an eventdev-based application (e.g., processing pipeline stages), > sharing the same underlying event device. > > The dispatcher replaces the conditional logic (often, a switch > statement) that typically follows an event device dequeue operation, > where events are dispatched to different parts of the application > based on event meta data, such as the queue id or scheduling type. > > The concept is similar to a UNIX file descriptor event loop library. > Instead of tying callback functions to fds as for example libevent > does, the dispatcher relies on application-supplied matching callback > functions to decide where to deliver events. > > A dispatcher is configured to dequeue events from a specific event > device, and ties into the service core framework, to do its (and the > application's) work. > > The dispatcher provides a convenient way for an eventdev-based > application to use service cores for application-level processing, and > thus for sharing those cores with other DPDK services. > > Although the dispatcher adds some overhead, experience suggests that > the net effect on the application (both synthetic benchmarks and more > real-world applications) may well be positive. This is primarily due > to clustering (see programming guide) reducing cache misses. > > Benchmarking indicates that the overhead is ~10 cc/event (on a > large core), with a handful of often-used handlers. > > The dispatcher does not support run-time reconfiguration. > > The use of the dispatcher library is optional, and an eventdev-based > application may still opt to access the event device using direct > eventdev API calls, or by some other means. My experience with event libraries is mixed. There are already multiple choices libevent, libev, and libsystemd as well as rte_epoll(). Not sure if adding another one is helpful. The main issue is dealing with external (non DPDK) events which usually are handled as file descriptors (signalfd, epoll, etc). The other issue is the thread safety. Most event libraries are not thread safe which makes handling one event waking up another difficult. With DPDK, there is the additional questions about use from non-EAL threads. For the test suite, you should look at what libsystemd does.
