-----Original Message----- > Date: Fri, 30 Jun 2017 13:08:26 +0000 > From: "Van Haaren, Harry" <harry.van.haa...@intel.com> > To: Jerin Jacob <jerin.ja...@caviumnetworks.com> > CC: "Richardson, Bruce" <bruce.richard...@intel.com>, "dev@dpdk.org" > <dev@dpdk.org>, "tho...@monjalon.net" <tho...@monjalon.net>, "Wiles, > Keith" <keith.wi...@intel.com> > Subject: RE: Service lcores and Application lcores > > > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > > Sent: Friday, June 30, 2017 1:52 PM > > To: Van Haaren, Harry <harry.van.haa...@intel.com> > > Cc: Richardson, Bruce <bruce.richard...@intel.com>; dev@dpdk.org; > > tho...@monjalon.net; > > Wiles, Keith <keith.wi...@intel.com> > > Subject: Re: Service lcores and Application lcores > > > > -----Original Message----- > > > Date: Fri, 30 Jun 2017 10:00:18 +0000 > > > From: "Van Haaren, Harry" <harry.van.haa...@intel.com> > > > To: Jerin Jacob <jerin.ja...@caviumnetworks.com>, "Richardson, Bruce" > > > <bruce.richard...@intel.com> > > > CC: "dev@dpdk.org" <dev@dpdk.org>, "tho...@monjalon.net" > > > <tho...@monjalon.net>, "Wiles, Keith" <keith.wi...@intel.com> > > > Subject: RE: Service lcores and Application lcores > > <snip previous non-related items> > > > > I don't think providing a remote-launch API is actually beneficial. > > > Remote-launching a > > single service > > > is equivalent to adding that lcore as a service-core, and mapping it to > > > just that single > > service. > > > The advantage of adding it as a service core, is future-proofing for if > > > more services > > need to be added > > > to that core in future, and statistics of the service core > > > infrastructure. A convenience > > API could be > > > provided to perform the core_add(), service_start(), enable_on_service() > > > and > > core_start() APIs in one. > > > > > > Also, the remote_launch API doesn't solve the original problem - what if > > > an application > > lcore wishes > > > to run one iteration of a service "manually". The remote_launch style API > > > does not solve > > this problem. > > > > Agree with problem statement. But, remote_launch() operates on lcores not on > > not necessary on 1:1 mapped physical cores. > > > > By introducing "rte_service_iterate", We are creating a parallel > > infrastructure to > > run the service on non DPDK service lcores aka normal lcores. > > Is this really required? Is there any real advantage for > > application not use builtin service lcore infrastructure, rather than > > iterating over > > "rte_service_iterate" and run on normal lcores. If we really want to mux > > a physical core to N lcore, EAL already provides that in the form of > > threads. > > > > I think, providing too many parallel options for the same use case may be > > a overkill. > > > > Just my 2c. > > > The use-case that the rte_service_iterate() caters for is one where the > application > wishes to run a service on an "ordinary app lcore", together with an > application workload. > > For example, the eventdev-scheduler and one worker can be run on the same > lcore. If the schedule() running thread *must* be a service lcore, we would > not be able to also use that lcore as an application worker core. > > That was my motivation for adding this API, I do agree with you above; it is > a second "parallel" method to run a service. I think there's enough value in > enabling the use-case as per example above to add it. > > > Do you see enough value in the use-case above to add the API?
The above use case can be realized like --lcores='(0-1)@1'(Two lcore on an physical core). I believe, application writers never want to write a code based on specific number of cores available in the system. If they do then they will be stuck on running on another environment and too many combination to address. For me it complicates service lcore usage. But someone think, it will useful then I don't have strong objection.
