[PATCH 03/29] examples/service_cores: correct documentation errors

Stephen Hemminger
2026-01-14T22:25:23Z

Address errors in service cores sample documentation:
- Change "registering applications" to "registering services"
- Add missing word: "can CPU cycles to" becomes
"can provide CPU cycles to"

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/sample_app_ug/service_cores.rst | 41 ++++++++++++----------
1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/doc/guides/sample_app_ug/service_cores.rst b/doc/guides/sample_app_ug/service_cores.rst
index 307a6c5fbb..cc44857d41 100644
--- a/doc/guides/sample_app_ug/service_cores.rst
+++ b/doc/guides/sample_app_ug/service_cores.rst
@@ -4,23 +4,26 @@
Service Cores Sample Application
================================

-The service cores sample application demonstrates the service cores capabilities
-of DPDK. The service cores infrastructure is part of the DPDK EAL, and allows
-any DPDK component to register a service. A service is a work item or task, that
+Overview
+--------
+
+This sample application demonstrates the service core capabilities
+of DPDK. The service core infrastructure is part of the DPDK EAL and allows
+any DPDK component to register a service. A service is a work item or task that
requires CPU time to perform its duty.

-This sample application registers 5 dummy services. These 5 services are used
-to show how the service_cores API can be used to orchestrate these services to
+This sample application registers 5 dummy services that are used
+to show how the service_cores API can orchestrate these services to
run on different service lcores. This orchestration is done by calling the
-service cores APIs, however the sample application introduces a "profile"
-concept to contain the service mapping details. Note that the profile concept
-is application specific, and not a part of the service cores API.
+service cores APIs. However, the sample application introduces a "profile"
+concept to contain service mapping details. Note that the profile concept
+is application-specific, and not a part of the service cores API.

Compiling the Application
-------------------------

-To compile the sample application see :doc:`compiling`.
+To compile the sample application, see :doc:`compiling`.

The application is located in the ``service_cores`` sub-directory.

@@ -39,8 +42,8 @@ pass a service core-mask as an EAL argument at startup time.
Explanation
-----------

-The following sections provide some explanation of code focusing on
-registering applications from an applications point of view, and modifying the
+The following sections provide explanation of the application code with focus on
+registering services from an application's point of view and modifying the
service core counts and mappings at runtime.

@@ -48,7 +51,7 @@ Registering a Service
~~~~~~~~~~~~~~~~~~~~~

The following code section shows how to register a service as an application.
-Note that the service component header must be included by the application in
+Note: The service component header must be included by the application in
order to register services: ``rte_service_component.h``, in addition
to the ordinary service cores header ``rte_service.h`` which provides
the runtime functions to add, remove and remap service cores.
@@ -80,7 +83,7 @@ Removing A Service Core
~~~~~~~~~~~~~~~~~~~~~~~

To remove a service core, the steps are similar to adding but in reverse order.
-Note that it is not allowed to remove a service core if the service is running,
+Note: It is not allowed to remove a service core if the service is running,
and the service-core is the only core running that service (see documentation
for ``rte_service_lcore_stop`` function for details).

@@ -88,9 +91,11 @@ for ``rte_service_lcore_stop`` function for details).
Conclusion
~~~~~~~~~~

-The service cores infrastructure provides DPDK with two main features. The first
-is to abstract away hardware differences: the service core can CPU cycles to
+The service cores infrastructure provides DPDK with two main features.
+
+The first is to abstract away hardware differences: the service core can provide CPU cycles to
a software fallback implementation, allowing the application to be abstracted
-from the difference in HW / SW availability. The second feature is a flexible
-method of registering functions to be run, allowing the running of the
-functions to be scaled across multiple CPUs.
+from the difference in HW / SW availability.
+
+The second feature is a flexible method of registering functions to be run,
+allowing the running of the functions to be scaled across multiple CPUs.
--
2.51.0