[dpdk-dev] [RFC] libeventdev: event driven programming model framework for DPDK
Jerin Jacob
jerin.jacob at caviumnetworks.com
Tue Aug 9 20:46:03 CEST 2016
On Tue, Aug 09, 2016 at 09:48:46AM +0100, Bruce Richardson wrote:
> On Tue, Aug 09, 2016 at 06:31:41AM +0530, Jerin Jacob wrote:
> > Find below the URL for the complete API specification.
> >
> > https://rawgit.com/jerinjacobk/libeventdev/master/rte_eventdev.h
> >
> > I have created a supportive document to share the concepts of
> > event driven programming model and proposed APIs details to get
> > better reach for the specification.
> > This presentation will cover introduction to event driven programming model concepts,
> > characteristics of hardware-based event manager devices,
> > RFC API proposal, example use case, and benefits of using the event driven programming model.
> >
> > Find below the URL for the supportive document.
> >
> > https://rawgit.com/jerinjacobk/libeventdev/master/DPDK-event_driven_programming_framework.pdf
> >
> > git repo for the above documents:
> >
> > https://github.com/jerinjacobk/libeventdev/
> >
> > Looking forward to getting comments from both application and driver
> > implementation perspective.
> >
>
> Hi Jerin,
>
Hi Bruce,
> thanks for the RFC. Packet distribution and scheduling is something we've been
> thinking about here too. This RFC gives us plenty of new ideas to take on board. :-)
Thanks
> While you refer to HW implementations on SOC's, have you given any thought to
> how a pure-software implementation of an event API might work? I know that
Yes. I have removed almost all hardware specific details from the API
specification. Mostly the APIs are driven by the use case.
I had impression that software based scheme will use
lib_rte_distributor or lib_rte_reorder libraries to get load balancing
and reordering features. However, if we are looking for some converged
solution without impacting the HW models then I think it is a good step
forward.
IMO, Implementing the ORDERED schedule sync method in a performance effective
way in the SW may be tricky. May be we can introduces some capability based
schemes to co-exists the HW and SW solution.
> while a software implemenation can obviously be done for just about any API,
> I'd be concerned that the API not get in the way of a very highly
> tuned implementation.
>
> We'll look at it in some detail and get back to you with our feedback, as soon
> as we can, to start getting the discussion going.
OK
>
> Regards,
> /Bruce
>
More information about the dev
mailing list