Hi Mattias, Please see inline.
Thanks, Anoob > -----Original Message----- > From: Mattias Rönnblom <mattias.ronnb...@ericsson.com> > Sent: Tuesday, July 2, 2019 11:08 PM > To: Anoob Joseph <ano...@marvell.com>; Thomas Monjalon > <tho...@monjalon.net>; Bruce Richardson <bruce.richard...@intel.com> > Cc: Jerin Jacob Kollanukkaran <jer...@marvell.com>; dev@dpdk.org; Nikhil Rao > <nikhil....@intel.com>; Erik Gabriel Carrillo <erik.g.carri...@intel.com>; > Abhinandan Gujjar <abhinandan.guj...@intel.com>; Pablo de Lara > <pablo.de.lara.gua...@intel.com>; Narayana Prasad Raju Athreya > <pathr...@marvell.com>; Lukas Bartosik <lbarto...@marvell.com>; Pavan > Nikhilesh Bhagavatula <pbhagavat...@marvell.com>; Hemant Agrawal > <hemant.agra...@nxp.com>; Nipun Gupta <nipun.gu...@nxp.com>; Harry van > Haaren <harry.van.haa...@intel.com>; Liang Ma <liang.j...@intel.com>; > techbo...@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.
