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. For an existing application to be moved to eventmode, all it would take is couple of function calls and fine-tuned worker thread. 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. > 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. The idea of this helper is to allow applications to run in "eventmode". Hence the name, eventmode_helper. > About the copy of the example itself, you are copying it as first patch of > this > series and then do improvements only to the copy, leaving the original behind. My original proposal (additions to l2fwd) was fixing quite a lot of things in the original app. Bruce was hesitant about the changes and suggested improvements only in the new app. I can add improvements in l2fwd also, if that's what you suggest. IMO, keeping both apps similar would be better for maintenance of l2fwd-event also. So, please suggest the approach. > So my suggestion is to do your PoC in a standalone example, improving the > original example at the same time, and try to improve the eventdev library if > possible. Then we should not propagate this design to more examples until we > have a proof that it is a progress. That is the proposal right now. L2fwd-event would be the standalone example. If code duplication is not a concern, I'll move the eventmode helper files to l2fwd-event directory. Then we can continue working on adding the features there before moving onto other examples. Please conclude deciding the approach to be taken. Thanks, Anoob > -----Original Message----- > From: Thomas Monjalon <tho...@monjalon.net> > Sent: Tuesday, July 2, 2019 8:27 PM > To: Anoob Joseph <ano...@marvell.com> > Cc: Jerin Jacob Kollanukkaran <jer...@marvell.com>; dev@dpdk.org; Mattias > Rönnblom <mattias.ronnb...@ericsson.com>; Nikhil Rao > <nikhil....@intel.com>; Erik Gabriel Carrillo <erik.g.carri...@intel.com>; > Abhinandan Gujjar <abhinandan.guj...@intel.com>; Bruce Richardson > <bruce.richard...@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 > > 02/07/2019 16:26, Jerin Jacob Kollanukkaran: > > From: Anoob Joseph > > > Hi Thomas, Jerin, > > > > > > Is there any consensus on how we should proceed? Can this be taken > > > up by techboard? > > OK, let me give my detailed opinion. > Summary: I don't like this situation at all. > > 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. > > About the copy of the example itself, you are copying it as first patch of > this > series and then do improvements only to the copy, leaving the original behind. > > 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. > > > For me it make sense to move these helper functions to examples/.. > > and make it as standalone(not as library) Suggested directory(In the > > order of my preference). No strong preference on the directory name > > though > > 1) examples/helper or > > 2) examples/common or > > 3) examples/utils > > If we are not able to give it a better name than "helper" or "utils", it is > like > moving it in a trash folder. > > And last but not least, there is not a lot of reaction to this series. > > So my suggestion is to do your PoC in a standalone example, improving the > original example at the same time, and try to improve the eventdev library if > possible. Then we should not propagate this design to more examples until we > have a proof that it is a progress. >
