All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	Jerin Jacob <jerin.jacob@caviumnetworks.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"Wiles, Keith" <keith.wiles@intel.com>
Subject: Re: [RFCv2] service core concept
Date: Tue, 6 Jun 2017 10:25:57 +0000	[thread overview]
Message-ID: <E923DB57A917B54B9182A2E928D00FA640C143CF@IRSMSX101.ger.corp.intel.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772583FB0525F@IRSMSX109.ger.corp.intel.com>

> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Saturday, June 3, 2017 11:23 AM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>; dev@dpdk.org
> Cc: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob <jerin.jacob@caviumnetworks.com>;
> Richardson, Bruce <bruce.richardson@intel.com>; Wiles, Keith <keith.wiles@intel.com>
> Subject: RE: [dpdk-dev] [RFCv2] service core concept

<snip>

> > In particular this version of the API enables applications that are not aware of services to
> > benefit from the services concept, as EAL args can be used to setup services and service
> cores.
> > With this design, switching to/from SW/HW PMD is transparent to the application. An example
> > use-case is the Eventdev HW PMD to Eventdev SW PMD that requires a service core.
> >
> > I have noted the implementation comments that were raised on the v1. For v2, I think our
> time
> > is better spent looking at the API design, and I will handle implementation feedback in the
> > follow-up patchset to v2 RFC.
> >
> > Below a summary of what we are trying to achieve, and the current API design.
> > Have a good weekend! Cheers, -Harry
> 
>
> Looks good to me in general.
> The only comment I have - do we really need to put it into rte_eal_init()
> and a new EAL command-line parameter for it?
> Might be better to leave it to the particular app to decide.


There are a number of options here, each with its own merit:

A) Services/cores config in EAL
Benefit is that service functionality can be transparent to the application. Negative is that the complexity is in EAL.

B) Application configures services/cores
Benefit is no added EAL complexity. Negative is that application code has to configure cores (duplicated per application).


To answer this question, I think we need to estimate how many applications would benefit from EAL integration and balance that against the "complexity cost" of doing so. I do like the simplicity of option (B), however if there is significant value in total transparency to the application I think (A) is the better choice.


Input on A) or B) welcomed! -Harry

  reply	other threads:[~2017-06-06 10:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-02 16:09 [RFCv2] service core concept Van Haaren, Harry
2017-06-03 10:22 ` Ananyev, Konstantin
2017-06-06 10:25   ` Van Haaren, Harry [this message]
2017-06-06 10:56     ` Ananyev, Konstantin
2017-06-06 14:53     ` Bruce Richardson
2017-06-06 15:29       ` Ananyev, Konstantin
2017-06-06 15:40         ` Van Haaren, Harry
2017-06-07  9:50           ` Ananyev, Konstantin
2017-06-07 10:29             ` Van Haaren, Harry
2017-06-07 13:09               ` Ananyev, Konstantin
2017-06-05  7:23 ` Jerin Jacob
2017-06-06 10:06   ` Van Haaren, Harry

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=E923DB57A917B54B9182A2E928D00FA640C143CF@IRSMSX101.ger.corp.intel.com \
    --to=harry.van.haaren@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=keith.wiles@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.