> -----Original Message----- > From: Anoob Joseph > Sent: Thursday, June 27, 2019 10:58 AM > To: Jerin Jacob Kollanukkaran <[email protected]>; Mattias Rönnblom > <[email protected]>; Nikhil Rao <[email protected]>; Erik > Gabriel Carrillo <[email protected]>; Abhinandan Gujjar > <[email protected]>; Bruce Richardson > <[email protected]>; Pablo de Lara > <[email protected]> > Cc: Narayana Prasad Raju Athreya <[email protected]>; [email protected]; > Lukas Bartosik <[email protected]>; Pavan Nikhilesh Bhagavatula > <[email protected]>; Hemant Agrawal > <[email protected]>; Nipun Gupta <[email protected]>; Harry > van Haaren <[email protected]>; Liang Ma > <[email protected]> > Subject: RE: [dpdk-dev] Re: [PATCH 00/39] adding eventmode helper library > > Hi Jerin, Mattias, > > Please see inline. > > Thanks, > Anoob > > > -----Original Message----- > > From: Jerin Jacob Kollanukkaran > > Sent: Tuesday, June 25, 2019 4:03 PM > > To: Anoob Joseph <[email protected]>; Mattias Rönnblom > > <[email protected]>; Nikhil Rao <[email protected]>; > > Erik Gabriel Carrillo <[email protected]>; Abhinandan Gujjar > > <[email protected]>; Bruce Richardson > > <[email protected]>; Pablo de Lara > > <[email protected]> > > Cc: Narayana Prasad Raju Athreya <[email protected]>; > [email protected]; > > Lukas Bartosik <[email protected]>; Pavan Nikhilesh Bhagavatula > > <[email protected]>; Hemant Agrawal > <[email protected]>; > > Nipun Gupta <[email protected]>; Harry van Haaren > > <[email protected]>; Liang Ma <[email protected]> > > Subject: RE: [dpdk-dev] Re: [PATCH 00/39] adding eventmode helper > > library > > > > > -----Original Message----- > > > From: Anoob Joseph > > > Sent: Thursday, June 20, 2019 9:15 AM > > > To: Mattias Rönnblom <[email protected]>; Jerin Jacob > > > Kollanukkaran <[email protected]>; Nikhil Rao > > > <[email protected]>; Erik Gabriel Carrillo > > > <[email protected]>; Abhinandan Gujjar > > > <[email protected]>; Bruce Richardson > > > <[email protected]>; Pablo de Lara > > > <[email protected]> > > > Cc: Narayana Prasad Raju Athreya <[email protected]>; > > [email protected]; > > > Lukas Bartosik <[email protected]>; Pavan Nikhilesh Bhagavatula > > > <[email protected]>; Hemant Agrawal > > <[email protected]>; > > > Nipun Gupta <[email protected]>; Harry van Haaren > > > <[email protected]>; Liang Ma <[email protected]> > > > Subject: RE: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode > > > helper library > > > > 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. > > > > > > I have only concern about moving this as library inside eventdev that > > till we have mature version of helper library the eventdev library ABI > > will not stable(i.e .so file version needs to be incremented as when a > > change needed). Which align with Mattias thoughts for some other > > reason:. How about moving this code to > > 1) example/common or > > 2) to specific application itself, once at least two applications > > starts using it then move to Eventdev library. > > > > Thoughts? > > [Anoob] Either location is not a problem if there is a consensus. Earlier the > suggestion was to move it to library (when the patch was submitted with > changes added in app).
If there NO objections then lets move to example/common. Cc: [email protected] for final decision on the location. > > Since there are other comments, which are being addressed, I would like to > send the next series with the current layout itself. And when we have an > agreement on the location to be used, I'll make the changes. Is that fine? > > > > > > > > > > > > > > > > > > > > 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
