Re: [dpdk-dev] [RFCv2] service core concept

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> -----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@caviumnetworks.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Wiles, Keith <keith.wiles@intel.com>
> Subject: RE: [dpdk-dev] [RFCv2] service core concept
> 
> > -----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.

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

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