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 15:29:14 +0000
Message-ID: <2601191342CEEE43887BDE71AB9772583FB06531@IRSMSX109.ger.corp.intel.com>
References: <E923DB57A917B54B9182A2E928D00FA63BF2D169@IRSMSX102.ger.corp.intel.com>
 <2601191342CEEE43887BDE71AB9772583FB0525F@IRSMSX109.ger.corp.intel.com>
 <E923DB57A917B54B9182A2E928D00FA640C143CF@IRSMSX101.ger.corp.intel.com>
 <20170606145347.GA55760@bricha3-MOBL3.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "dev@dpdk.org" <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>,
 Jerin Jacob <jerin.jacob@caviumnetworks.com>, "Wiles, Keith"
 <keith.wiles@intel.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>, "Van Haaren, Harry"
 <harry.van.haaren@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id 20BE0567C
 for <dev@dpdk.org>; Tue,  6 Jun 2017 17:29:18 +0200 (CEST)
In-Reply-To: <20170606145347.GA55760@bricha3-MOBL3.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: Richardson, Bruce
> Sent: Tuesday, June 6, 2017 3:54 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev@dpdk.org; Tho=
mas Monjalon <thomas@monjalon.net>; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>; Wiles, Keith <keith.wiles@intel.com>
> Subject: Re: [dpdk-dev] [RFCv2] service core concept
>=20
> On Tue, Jun 06, 2017 at 11:25:57AM +0100, Van Haaren, Harry wrote:
> > > -----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@c=
aviumnetworks.com>;
> > > Richardson, Bruce <bruce.richardson@intel.com>; Wiles, Keith <keith.w=
iles@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 implem=
entation feedback in the
> > > > follow-up patchset to v2 RFC.
> > > >
> > > > Below a summary of what we are trying to achieve, and the current A=
PI 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_in=
it()
> > > 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 applica=
tion. Negative is that the complexity is in EAL.
> >
> > B) Application configures services/cores
> > Benefit is no added EAL complexity. Negative is that application code h=
as to configure cores (duplicated per application).
> >
> >
> > To answer this question, I think we need to estimate how many applicati=
ons 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
>=20
> I'm definitely in favour of having it in EAL. The whole reason for doing
> this work is to make it easy for applications to dedicate cores to
> background tasks - including applications written before this
> functionality was added. By merging this into EAL, we can have
> transparency in the app, as we can have the service cores completely in
> the background, and the app can call rte_eal_mp_remote_launch() exactly
> as before, without unexpected failures. If we move this externally, the
> app needs to be reworked to take account of that fact, and call new,
> service-core aware, launch functions instead.

Not sure I understood you here:
If the app don' plan to use any cores for services, it for sure will be abl=
e to call
rte_eal_mp_remote_launch() as before (no services running case).
>>From other side, if the app would like to use services - it would need to s=
pecify
which service it wants to run, and for each service provide a coremask, eve=
n if
EAL already allocates service cores for it.
Or are you talking about the when EAL allocates service cores, and then
PMDs themselves (or EAL again) register their services on that cores?
That's probably possible, but how PMD would know which service core(s) it a=
llowed to use?
Another EAL cmd-line parameter(s) or extension of existing '-w/--vdev' or s=
omething else?
Things might get over-complicated here - in theory there could be multiple =
PMDs,
each of them can have more than one service, running on multiple sets of co=
res, etc.
Konstantin

=20