Hi Stephen,
On 3/4/2015 8:52 AM, Stephen Hemminger wrote: > On Fri, 27 Feb 2015 11:38:25 +0100 > David Marchand <david.marchand at 6wind.com> wrote: > >> Ok, so after looking at this patchset, I would say this is the right >> direction, but still this is too limited. >> The ethdev part and the vfio eventfds part look acceptable to me. >> But thinking about it, I could just reuse a standard event library with the >> eventfds I would get from ethdev without a need for a new eal api. > I would prefer that there was just an fd and a callback. > An application should be able to use what ever event model or library it > wants. [LCM] I agree, on application perspective it is. As it's easy to get RX/TX interrupt fd, there's no limit for application to do all the things with the 3rd party event library. The improvement probably be 1) a rte_intr_vec_to_fd() API; 2) expose eal_intr_process_rxtx_interrupts() as a public API for RX/TX interrupt callback. However, it should allow to use the packet interrupt feature in case application don't choose any 3rd party event library. That's the motivation to give a very lightweight 'wait' EAL API. Sounds reasonable ? > > IMHO the existing interrupt thread model is incorrectly designed and creates > lots of opportunities for races because of that. Look at the effort it has to > use to pass the event back to link state code.
