Re: Service lcores and Application lcores

From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
Sent: Friday, June 30, 2017 2:21 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 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

quoted

quoted

single service

quoted

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

single

quoted

quoted

service.

quoted

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

services

quoted

quoted

need to be added

quoted

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

convenience

quoted

quoted

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

quoted

quoted

lcore wishes

quoted

to run one iteration of a service "manually". The remote_launch style API does not

solve

quoted

quoted

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.

quoted

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.

quoted

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.

quoted

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.

Good point.

For me it complicates service lcore usage. But someone think, it will useful then
I don't have strong objection.

We can easily add APIs later - and removing them isn't so easy. +1 from me leave it out for now, and we can see about adding it for 17.11 if the need arises.

Thanks for your input, I'll spin a v3 without the rte_service_iterate() function, and that should be it then!