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

[Anoob Joseph <anoobj@marvell.com>]

Hi Mattias,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> Sent: Tuesday, July 2, 2019 11:08 PM
> To: Anoob Joseph <anoobj@marvell.com>; Thomas Monjalon
> <thomas@monjalon.net>; Bruce Richardson <bruce.richardson@intel.com>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org; Nikhil Rao
> <nikhil.rao@intel.com>; Erik Gabriel Carrillo <erik.g.carrillo@intel.com>;
> Abhinandan Gujjar <abhinandan.gujjar@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry van
> Haaren <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>;
> techboard@dpdk.org
> Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper
> library
> 
> On 2019-07-02 18:18, Anoob Joseph wrote:
> > Hi Thomas, Bruce,
> >
> >> For what exactly is being proposed, is there a short version of the suggested
> approach and the logic behind it?
> >> I think eventdev should be simple to use and could be added to any
> >> example like l2fwd. The idea of forking an example, where we should
> >> be able to have an unified API, is a proof of failure.
> >
> > As Mattias had mentioned earlier, eventdev is complicated because of a
> reason. It exposes lot of configuration which can be used to dynamically load-
> balance real world traffic. With various adapters like, Rx adapter, Tx adapter,
> crypto adapter etc getting implemented, applications can better utilize
> capabilities of event device. But all the existing example applications in DPDK is
> designed around mbufs and polling of cores on various devices. If an application
> has to fully leverage capabilities of an event device, it has to setup all these
> adapters and devices. And, as Mattias had mentioned, this involves lot of
> configuration. This configuration would be repeated for every application which
> would need to run in eventmode. Eventmode helper abstracts this.
> >
> 
> A question I asked myself when I had a look at the patch set is: does eventmode
> really abstract processing pipeline configuration, or is it merely making a bunch
> of assumptions and hard-coding a bunch of configuration parameters.
> 
> Merely reducing flexibility doesn't qualify as abstraction, I would say.

[Anoob] The idea is not to remove flexibility. All options of adapters would be exposed as command line args/ config file. For the first version, I didn't add it because it would exponentially increase the code. 
 
> 
>  > For an existing application to be moved to eventmode, all it would take is
> couple of function calls and fine-tuned worker thread.
> 
> If you want to use eventdev as a very complex implementation of software RSS,
> sure.
> 
> If you have a problem which solution requires a multi-stage pipeline, going from
> a run-to-completion model to a scheduled pipeline is going to have a big impact
> on your code base, and eventdev configuration will be a relatively minor part of
> the work, in the typical case, I would expect.

[Anoob] Why do you say this approach cannot work in multi stage environment? You need to increase the number of event ports & queues as required (using command line args). Few ports & queues would be used by Rx adapter & Tx adapter. Rest will be available for the application to do the multi-stage pipeline.

Also, for some applications, this complexity is not needed. Say, for l2fwd, none of this complexity is needed. When we attempt ipsec-secgw, multi-stage might come into picture.

> 
> > Just to remind, this is the 3rd iteration of submitting patches. The first set of
> patches were submitted by Sunil Kori from NXP and that involved additions in
> l3fwd application. It involved addition of lot of code, and Bruce wanted to make
> the additions common. Jerin suggested to add these in event dev library.
> >
> > The second iteration involved additions in l2fwd and introduced eventmode in
> eventdev library. Then it was up for discussions again and it was decided that for
> l2fwd, a new application for eventmode would be drafted, but for l3fwd & ipsec-
> secgw, the original application would get additions. L2fwd-event will be used to
> finalize the event-mode library before extending to other applications.
> >
> > Now this is the third iteration.
> >
> 
> What is your point?

[Anoob] We had been doing back and forth regarding approaches. If applications like l2fwd, l3fwd, ipsec-secgw etc shouldn't deal with events, it could've been decided in the first submission itself.
 
> 
> >> About the helper, I see some command line processing and other things
> which have nothing to do in a library.
> >> Actually I fail to understand the global idea of this helper.
> >> There is no description of what this helper is, and even no name for it.
> >
> > All the eventmode configuration need to be user defined. So either every
> application would need the code duplicated (how the code for lcore-port-queue
> conf required for eth devs is repeated in every app) or be kept common. Again,
> that can be kept as a separate header and can be copied around. I don't see any
> issue, if you are fine with it.
> >
> 
> OK, so in real-world applications, duplicating eventdev configuration is not a
> major concern. You will have very few applications, and if they have a similar
> structure, you can reuse your proprietary framework. If they don't, no big deal.
> Just an additional 1% of application code to maintain.
> 
> For the DPDK example applications, the situation is very different. Many trivial
> applications with a similar structure. I'm sure solving the framework problem for
> this subset of applications is easier, but I would expect such a library would have
> limited value outside the realm of the example directory. Although it might make
> the DPDK example code base more maintainable, my fear is that it'll just confuse
> the reader of the example applications. Now they have to understand a
> framework *and* an application, and not only the example application. Add to
> this that the framework you just spent time understanding will also not provide -
> at least not in its current form - a good foundation for non-trivial applications.
> 
> The DPDK APIs shouldn't be optimized for example applications.

[Anoob] Initially the target would be only DPDK applications. As I had mentioned earlier, I'm dropping the idea of making this a library/common code. My proposal is to have all the code in l2fwd-event application itself. In that case, would you have any problem?

None of the DPDK APIs would be modified in this effort.

When Bruce looked at the patches I had submitted to l2fwd, his opinion was, there is lot of code to just do initialization & configuration. But here you are saying, that code is very minimal compared to the applications. These are all perspectives and I would like to get a consensus.