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 >
