Re: Service lcores and Application lcores

-----Original Message-----

Date: Fri, 30 Jun 2017 13:08:26 +0000
From: "Van Haaren, Harry" <redacted>
To: Jerin Jacob <redacted>
CC: "Richardson, Bruce" <redacted>, "dev@dpdk.org"
 [off-list ref], "thomas@monjalon.net" [off-list ref], "Wiles,
 Keith" [off-list ref]
Subject: RE: Service lcores and Application lcores

quoted

From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
Sent: Friday, June 30, 2017 1:52 PM
To: Van Haaren, Harry <redacted>
Cc: Richardson, Bruce <redacted>; dev@dpdk.org; thomas@monjalon.net;
Wiles, Keith [off-list ref]
Subject: Re: Service lcores and Application lcores

-----Original Message-----

quoted

Date: Fri, 30 Jun 2017 10:00:18 +0000
From: "Van Haaren, Harry" <redacted>
To: Jerin Jacob <redacted>, "Richardson, Bruce"
 [off-list ref]
CC: "dev@dpdk.org" <redacted>, "thomas@monjalon.net"
 [off-list ref], "Wiles, Keith" [off-list ref]
Subject: RE: Service lcores and Application lcores

<snip previous non-related items>

quoted

quoted

I don't think providing a remote-launch API is actually beneficial. Remote-launching a

single service

quoted

is equivalent to adding that lcore as a service-core, and mapping it to just that single

service.

quoted

The advantage of adding it as a service core, is future-proofing for if more services

need to be added

quoted

to that core in future, and statistics of the service core infrastructure. A convenience

API could be

quoted

provided to perform the core_add(), service_start(), enable_on_service() and

core_start() APIs in one.

quoted

Also, the remote_launch API doesn't solve the original problem - what if an application

lcore wishes

quoted

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.