archive mirror
 help / color / mirror / Atom feed
From: Anoob Joseph <>
To: "Mattias Rönnblom" <>,
	"Thomas Monjalon" <>,
	"Bruce Richardson" <>
Cc: Jerin Jacob Kollanukkaran <>,
	"" <>, Nikhil Rao <>,
	Erik Gabriel Carrillo <>,
	Abhinandan Gujjar <>,
	Pablo de Lara <>,
	Narayana Prasad Raju Athreya <>,
	Lukas Bartosik <>,
	"Pavan Nikhilesh Bhagavatula" <>,
	Hemant Agrawal <>,
	Nipun Gupta <>,
	Harry van Haaren <>,
	Liang Ma <>,
	"" <>
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library
Date: Wed, 3 Jul 2019 01:35:11 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Mattias,

Please see inline.


> -----Original Message-----
> From: Mattias Rönnblom <>
> Sent: Tuesday, July 2, 2019 11:08 PM
> To: Anoob Joseph <>; Thomas Monjalon
> <>; Bruce Richardson <>
> Cc: Jerin Jacob Kollanukkaran <>;; Nikhil Rao
> <>; Erik Gabriel Carrillo <>;
> Abhinandan Gujjar <>; Pablo de Lara
> <>; Narayana Prasad Raju Athreya
> <>; Lukas Bartosik <>; Pavan
> Nikhilesh Bhagavatula <>; Hemant Agrawal
> <>; Nipun Gupta <>; Harry van
> Haaren <>; Liang Ma <>;
> 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.

  reply	other threads:[~2019-07-03  1:35 UTC|newest]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).