From: Anoob Joseph <firstname.lastname@example.org> To: "Mattias Rönnblom" <email@example.com>, "Thomas Monjalon" <firstname.lastname@example.org>, "Bruce Richardson" <email@example.com> Cc: Jerin Jacob Kollanukkaran <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Nikhil Rao <email@example.com>, Erik Gabriel Carrillo <firstname.lastname@example.org>, Abhinandan Gujjar <email@example.com>, Pablo de Lara <firstname.lastname@example.org>, Narayana Prasad Raju Athreya <email@example.com>, Lukas Bartosik <firstname.lastname@example.org>, "Pavan Nikhilesh Bhagavatula" <email@example.com>, Hemant Agrawal <firstname.lastname@example.org>, Nipun Gupta <email@example.com>, Harry van Haaren <firstname.lastname@example.org>, Liang Ma <email@example.com>, "firstname.lastname@example.org" <email@example.com> Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library Date: Wed, 3 Jul 2019 01:35:11 +0000 Message-ID: <MN2PR18MB28776E87ACDC6E576E424A45DFFB0@MN2PR18MB2877.namprd18.prod.outlook.com> (raw) In-Reply-To: <firstname.lastname@example.org> Hi Mattias, Please see inline. Thanks, Anoob > -----Original Message----- > From: Mattias Rönnblom <email@example.com> > Sent: Tuesday, July 2, 2019 11:08 PM > To: Anoob Joseph <firstname.lastname@example.org>; Thomas Monjalon > <email@example.com>; Bruce Richardson <firstname.lastname@example.org> > Cc: Jerin Jacob Kollanukkaran <email@example.com>; firstname.lastname@example.org; Nikhil Rao > <email@example.com>; Erik Gabriel Carrillo <firstname.lastname@example.org>; > Abhinandan Gujjar <email@example.com>; Pablo de Lara > <firstname.lastname@example.org>; Narayana Prasad Raju Athreya > <email@example.com>; Lukas Bartosik <firstname.lastname@example.org>; Pavan > Nikhilesh Bhagavatula <email@example.com>; Hemant Agrawal > <firstname.lastname@example.org>; Nipun Gupta <email@example.com>; Harry van > Haaren <firstname.lastname@example.org>; Liang Ma <email@example.com>; > firstname.lastname@example.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.
next prev parent reply index Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-25 10:33 [dpdk-dev] " Jerin Jacob Kollanukkaran 2019-06-27 5:28 ` Anoob Joseph 2019-06-28 3:37 ` Jerin Jacob Kollanukkaran 2019-06-28 8:02 ` Mattias Rönnblom 2019-06-28 8:40 ` Thomas Monjalon 2019-06-28 9:07 ` Mattias Rönnblom 2019-06-28 11:34 ` [dpdk-dev] [EXT] " Anoob Joseph 2019-07-02 14:17 ` Anoob Joseph 2019-07-02 14:26 ` Jerin Jacob Kollanukkaran 2019-07-02 14:49 ` Bruce Richardson 2019-07-02 14:57 ` Thomas Monjalon 2019-07-02 16:18 ` Anoob Joseph 2019-07-02 17:38 ` Mattias Rönnblom 2019-07-03 1:35 ` Anoob Joseph [this message] 2019-07-03 8:51 ` Thomas Monjalon 2019-07-03 9:37 ` Anoob Joseph 2019-07-03 16:30 ` Thomas Monjalon 2019-07-04 3:34 ` Anoob Joseph -- strict thread matches above, loose matches on Subject: below -- 2019-06-03 17:32 [dpdk-dev] " Anoob Joseph 2019-06-07 9:48 ` Jerin Jacob Kollanukkaran 2019-06-11 10:44 ` Mattias Rönnblom 2019-06-14 9:18 ` [dpdk-dev] [EXT] " Anoob Joseph 2019-06-17 13:23 ` Mattias Rönnblom 2019-06-20 3:44 ` Anoob Joseph
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=MN2PR18MB28776E87ACDC6E576E424A45DFFB0@MN2PR18MB2877.namprd18.prod.outlook.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
DPDK-dev Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/dpdk-dev/0 dpdk-dev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 dpdk-dev dpdk-dev/ https://lore.kernel.org/dpdk-dev \ email@example.com public-inbox-index dpdk-dev Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.dpdk.dev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git