archive mirror
 help / color / mirror / Atom feed
From: "Mattias Rönnblom" <>
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
Date: Tue, 2 Jul 2019 19:38:14 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.

 > 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.

> 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?

>> 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 

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 

The DPDK APIs shouldn't be optimized for example applications.

  reply	other threads:[~2019-07-02 17:38 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-25 10:33 [dpdk-dev] [PATCH 00/39] adding eventmode helper library 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 [this message]
2019-07-03  1:35                   ` Anoob Joseph
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 \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).