> -----Original Message----- > From: Van Haaren, Harry > Sent: Tuesday, June 6, 2017 11:26 AM > To: Ananyev, Konstantin <konstantin.anan...@intel.com>; dev@dpdk.org > Cc: Thomas Monjalon <tho...@monjalon.net>; Jerin Jacob > <jerin.ja...@caviumnetworks.com>; Richardson, Bruce > <bruce.richard...@intel.com>; Wiles, Keith <keith.wi...@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.haa...@intel.com>; dev@dpdk.org > > Cc: Thomas Monjalon <tho...@monjalon.net>; Jerin Jacob > > <jerin.ja...@caviumnetworks.com>; > > Richardson, Bruce <bruce.richard...@intel.com>; Wiles, Keith > > <keith.wi...@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
