[dpdk-dev] [PATCH v6 0/8] Interrupt mode PMD

Liang, Cunming cunming.liang at intel.com
Wed Mar 4 04:20:32 CET 2015


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.


More information about the dev mailing list