epoll/libevent vs. AEM (was RE: [cgl_discussion] PoC concall 10/8/03 Minutes)

Fleischer, Julie N julie.n.fleischer at intel.com
Mon Oct 13 13:09:13 PDT 2003


> I have some update information and thoughts for epoll + 
> libevent. Hope it's helpful.

>From previous analysis on the mailing list I have:
For AEM - Meets requirements: scalability for large # event channels - w/forked events; soft RT resp. for ~simultaneous events - with RT patch; events on Xpl types of channels - only timer and socket -->work needed for SCTP; all kernel level

For epoll+libevent:
Meets some requirements: is synchronous polling mechanism - http://aem.sourceforge.net/reports/aem-faq-draf0.3.pdf; scalability for large # event chs - epoll + libevent does; soft RT resp. for ~sim events - does, may not be as good as AEM (need analysis); events on Xpl types of chs - supports Xpl channels, only read, but accept/read/write/exception on socket, others impl. dependent, so OK

To sum up, it appears:
- AEM will meet full requirements when complete -- It's on the top-10 because CGL has expressed concern about stability/invasiveness.
- libevent+epoll has a few issues:  1)  It's synchronous, not asynchronous.  2) Soft RT response for nearly simultaneous events may not match AEM -- needs testing.  3) libevent can't support SMP (from Forrest's analysis).

Is this enough for us to have a discussion about the Efficient Low-Level Asynchronous Events requirement at the next PoC or F2F?  It definitely sounds like AEM should stay on the top-10, though, since it's still unclear if epoll+libevent will fulfill the requirement.  (Possibly, though, it fulfills enough of the spirit of the requirement that it's acceptable.)

- Julie

**These views are not necessarily those of my employer.**



More information about the cgl_discussion mailing list