DPDK-dev Archive on lore.kernel.org
 help / color / Atom feed
From: Anoob Joseph <anoobj@marvell.com>
To: "Mattias Rönnblom" <mattias.ronnblom@ericsson.com>,
	"Thomas Monjalon" <thomas@monjalon.net>,
	"Bruce Richardson" <bruce.richardson@intel.com>
Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	"dev@dpdk.org" <dev@dpdk.org>, Nikhil Rao <nikhil.rao@intel.com>,
	Erik Gabriel Carrillo <erik.g.carrillo@intel.com>,
	Abhinandan Gujjar <abhinandan.gujjar@intel.com>,
	Pablo de Lara <pablo.de.lara.guarch@intel.com>,
	Narayana Prasad Raju Athreya <pathreya@marvell.com>,
	Lukas Bartosik <lbartosik@marvell.com>,
	"Pavan Nikhilesh Bhagavatula" <pbhagavatula@marvell.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>,
	Nipun Gupta <nipun.gupta@nxp.com>,
	Harry van Haaren <harry.van.haaren@intel.com>,
	Liang Ma <liang.j.ma@intel.com>,
	"techboard@dpdk.org" <techboard@dpdk.org>
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: <27d46871-fa0c-1144-b7fa-8c57154478b3@ericsson.com>

Hi Mattias,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> Sent: Tuesday, July 2, 2019 11:08 PM
> To: Anoob Joseph <anoobj@marvell.com>; Thomas Monjalon
> <thomas@monjalon.net>; Bruce Richardson <bruce.richardson@intel.com>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org; Nikhil Rao
> <nikhil.rao@intel.com>; Erik Gabriel Carrillo <erik.g.carrillo@intel.com>;
> Abhinandan Gujjar <abhinandan.gujjar@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry van
> Haaren <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>;
> techboard@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.

  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 publically 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 \
    --to=anoobj@marvell.com \
    --cc=abhinandan.gujjar@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=erik.g.carrillo@intel.com \
    --cc=harry.van.haaren@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerinj@marvell.com \
    --cc=lbartosik@marvell.com \
    --cc=liang.j.ma@intel.com \
    --cc=mattias.ronnblom@ericsson.com \
    --cc=nikhil.rao@intel.com \
    --cc=nipun.gupta@nxp.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=pathreya@marvell.com \
    --cc=pbhagavatula@marvell.com \
    --cc=techboard@dpdk.org \
    --cc=thomas@monjalon.net \
    /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 \
		dev@dpdk.org
	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