From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Subject: Re: [RFCv2] service core concept
Date: Tue, 6 Jun 2017 10:56:07 +0000
Message-ID: <2601191342CEEE43887BDE71AB9772583FB06145@IRSMSX109.ger.corp.intel.com>
References: <E923DB57A917B54B9182A2E928D00FA63BF2D169@IRSMSX102.ger.corp.intel.com>
 <2601191342CEEE43887BDE71AB9772583FB0525F@IRSMSX109.ger.corp.intel.com>
 <E923DB57A917B54B9182A2E928D00FA640C143CF@IRSMSX101.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Monjalon <thomas@monjalon.net>, Jerin Jacob
 <jerin.jacob@caviumnetworks.com>, "Richardson, Bruce"
 <bruce.richardson@intel.com>, "Wiles, Keith" <keith.wiles@intel.com>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>, "dev@dpdk.org"
 <dev@dpdk.org>
Return-path: <dev-bounces@dpdk.org>
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
 by dpdk.org (Postfix) with ESMTP id 8C0484BE1
 for <dev@dpdk.org>; Tue,  6 Jun 2017 12:56:17 +0200 (CEST)
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA640C143CF@IRSMSX101.ger.corp.intel.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>



> -----Original Message-----
> From: Van Haaren, Harry
> Sent: Tuesday, June 6, 2017 11:26 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev@dpdk.org
> Cc: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob <jerin.jacob@caviu=
mnetworks.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Wiles, Keith <keith.wiles@intel.com>
> Subject: RE: [dpdk-dev] [RFCv2] service core concept
>=20
> > -----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@cav=
iumnetworks.com>;
> > Richardson, Bruce <bruce.richardson@intel.com>; Wiles, Keith <keith.wil=
es@intel.com>
> > Subject: RE: [dpdk-dev] [RFCv2] service core concept
>=20
> <snip>
>=20
> > > In particular this version of the API enables applications that are n=
ot aware of services to
> > > benefit from the services concept, as EAL args can be used to setup s=
ervices and service
> > cores.
> > > With this design, switching to/from SW/HW PMD is transparent to the a=
pplication. An example
> > > use-case is the Eventdev HW PMD to Eventdev SW PMD that requires a se=
rvice 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 implemen=
tation 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.
>=20
>=20
> There are a number of options here, each with its own merit:
>=20
> A) Services/cores config in EAL
> Benefit is that service functionality can be transparent to the applicati=
on. Negative is that the complexity is in EAL.

It is not only complexity of EAL, as I understand, it would mean that
EAL will have a dependency on this new library.
Konstantin

>=20
> B) Application configures services/cores
> Benefit is no added EAL complexity. Negative is that application code has=
 to configure cores (duplicated per application).
>=20
>=20
> To answer this question, I think we need to estimate how many application=
s 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.
>=20
>=20
> Input on A) or B) welcomed! -Harry