[dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library

[Anoob Joseph]

Hi Mattias,

Please see my response inline.

Thanks,
Anoob

> -----Original Message-----
> From: dev <dev-bounces at dpdk.org> On Behalf Of Mattias Rönnblom
> Sent: Monday, June 17, 2019 6:54 PM
> To: Anoob Joseph <anoobj at marvell.com>; Jerin Jacob Kollanukkaran
> <jerinj at marvell.com>; Nikhil Rao <nikhil.rao at intel.com>; Erik Gabriel Carrillo
> <erik.g.carrillo at intel.com>; Abhinandan Gujjar
> <abhinandan.gujjar at intel.com>; Bruce Richardson
> <bruce.richardson at intel.com>; Pablo de Lara
> <pablo.de.lara.guarch at intel.com>
> Cc: Narayana Prasad Raju Athreya <pathreya at marvell.com>; dev at dpdk.org;
> Lukas Bartosik <lbartosik at marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula at marvell.com>; Hemant Agrawal
> <hemant.agrawal at nxp.com>; Nipun Gupta <nipun.gupta at nxp.com>; Harry
> van Haaren <harry.van.haaren at intel.com>; Liang Ma
> <liang.j.ma at intel.com>
> Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper
> library
> 
> On 2019-06-14 11:18, Anoob Joseph wrote:
> > Hi Mattias,
> >
> >> A more extensive description of the purpose of the eventmode helper
> >> library would be helpful.
> >>
> >> Is this supposed to be a generic framework for real-world
> >> applications, or only something to simplify DPDK the implementation
> >> of DPDK example programs and similar?
> >
> > This is intended as a generic framework, but the initial targets would be
> limited to DPDK example applications.
> >
> > For any application to use an event device for dynamic load balancing, it has
> to configure the event device and the adapters. Configuring the adapters
> would involve providing various parameters based on which the dynamic
> scheduling should happen. But requiring the application to do all this
> configuration would make the application complicated as well as the same
> code has to be repeated for a new application. Event mode helper tries to
> solve that.
> >
> > All the complex configuration would be implemented by the helper library
> and the helper library would provide a default conf as well.
> >
> 
> The task of configuring eventdev and its adaptors, and ethernet devices is a
> daunting task indeed. If we could simplify that, that would be great.
> 
> However, the flexibility and many of the parameters are there for a reason
> (those there aren't should be deprecated). I would expect a real-world
> application to tweak quite a few of them. I know our applications do.
> 
> I worry I have is that if you put eventmode (in its current form) forward as a
> generic framework, applications might start using it, only to realize it's not
> flexible enough, and then eventmode is just an extra layer, increasing rather
> than reducing complexity. Or even worse, the application's developers are
> forced to do a big-bang switch over to using the event and ethernet device
> APIs directly, in case they can't patch DPDK to work around the eventmode-
> assumption-that-didn't-hold-for-them.
> 
> You could always add flexibility to the framework (as you encounter a need
> for it), but then it will grow in complexity as well.
> 
> A less ambitious approach would be to instead do a properly modularized,
> non-trivial eventdev example application, for the applications to start off
> from, instead of a generic library.
> 
> I would expect it to be very difficult to design a truly generic application
> framework for eventdev-based applications. Such a framework would tie
> everything that's needed in a non-trivial application together. If successful, it
> would be a huge step toward making DPDK an operating system for packet
> processing applications.

[Anoob] The idea here is not to deprecate any event dev APIs. I do agree that all the configuration exposed by eventdev & adapters are required for various requirements in the real world applications. But the requirement to understand & use all this configuration is making the applications complicated and causes significant effort from anyone who would want to get started with event mode. The idea of helper is to allow an easy framework for applications to get started with eventmode, and then use various options from C/L or config file (both planned) to override the configuration as required. DPDK has components like crypto-scheduler which abstracts lot of configuration and simplify usage from application's perspective. This effort is on similar lines.

My patchset is a followup to http://patches.dpdk.org/patch/37955 , wherein the approach of introducing a helper library for event mode was mooted. The initial patch proposed additions in one application, and that involved huge code additions just for doing the configuration.

The helper library will be experimental while we add event-mode support for other applications like l3fwd & ipsec-secgw. I expect the helper library to be complete over the course of those applications also using the helper library.

> 
> What event devices have you tested with?

[Anoob] Eventmode helper is tested with the following combinations, 
    1. event-octeontx event PMD & nicvf eth PMD
    2. event-octeontx event PMD & eth-octeontx eth PMD