From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harry van Haaren Subject: [PATCH v5 0/7] service cores: cover letter Date: Tue, 11 Jul 2017 15:19:26 +0100 Message-ID: <1499782773-12277-1-git-send-email-harry.van.haaren@intel.com> References: <1499445667-32588-1-git-send-email-harry.van.haaren@intel.com> Cc: thomas@monjalon.net, jerin.jacob@caviumnetworks.com, keith.wiles@intel.com, bruce.richardson@intel.com, Harry van Haaren To: dev@dpdk.org Return-path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 34E1F3257 for ; Tue, 11 Jul 2017 16:19:33 +0200 (CEST) In-Reply-To: <1499445667-32588-1-git-send-email-harry.van.haaren@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" This patchset introduces service cores to DPDK. A service core is an lcore that performs functions to abstract away details of differences in environment of the application. An example is using the eventdev API, where either a software or hardware PMD performs scheduling. In the case of the software PMD an lcore is required to perform scheduling, which means application logic would have to be aware of the PMD running under the API. To abstract away the differences in HW / SW PMDs, service cores can run the SW PMD service without application logic specifying the exact cores to use. Note that eventdev is only one API that benefits; timers, interrupts handling, statistics and monitoring, and a range of other infrastructure that requires a slice of CPU time may all benefit from service cores. The application is not obliged to manually use the service cores API, however if an application wishes to use the service cores API for fine grained control over how the services are run, this is possible. Deciding between a performance threading-profile and scaled-down profile can be achieved by advanced usage of service cores and setting the lcore mappings. Patch 5/7 shows how a PMD can register a service to run a function. This is then available (along with any other registered services) to be run by the service cores. Patches 6/7 and 7/7 add documentation, and claim maintainership. Regards, -Harry v5: Jerin: - Fix documentation warnings - Rename variables to better names - Enable statistics per-service - Improve atomic operation flag checks - Reworked function to rte_service_start_with_defaults() - Added memory barriers to lcore_add() and lcore_del() - Simplified EAL code, reduced duplication and makes it more maintainable Jerin/Thomas: - Rename component header to rte_service_component.h v4: - Range of fixes as suggested by Jerin - Improved unit tests, ensuring ex-service cores become available to app - Added functions to EXPERIMENTAL tag in .map files (Thomas) - Added @warning experimental notes to Doxygen API documentation (Thomas) - Various smaller fixes / cleanups - See commit notes for details v3: - Added docs - Added release notes - Updated maintainers file - Compile checks with devtools/test-build.sh - Validated patches apply to latest dpdk/master - Based on discussion, rte_service_iterate() is *not* included, but could be adding at a later date if use-cases require it. - Future work includes enabling the eventdev_pipeline sample app, but there is still some churn there to enable both HW/SW PMDs seamlessly. Once sample app is enabled a service core walk-through with that sample app can be added to the docs, to provide a tutorial on service-core usage. Harry van Haaren (7): service cores: header and implementation service cores: EAL init changes service cores: coremask parsing service cores: add unit tests event/sw: enable SW PMD with service capability doc: add service cores to doc and release notes maintainers: claim service cores MAINTAINERS | 7 + doc/api/doxy-api-index.md | 1 + doc/guides/eventdevs/sw.rst | 4 +- doc/guides/prog_guide/index.rst | 1 + doc/guides/prog_guide/service_cores.rst | 81 +++ doc/guides/rel_notes/release_17_08.rst | 8 + drivers/event/sw/sw_evdev.c | 32 + drivers/event/sw/sw_evdev.h | 3 + lib/librte_eal/bsdapp/eal/Makefile | 1 + lib/librte_eal/bsdapp/eal/eal.c | 18 + lib/librte_eal/bsdapp/eal/rte_eal_version.map | 23 + lib/librte_eal/common/Makefile | 1 + lib/librte_eal/common/eal_common_lcore.c | 1 + lib/librte_eal/common/eal_common_options.c | 91 ++- lib/librte_eal/common/include/rte_eal.h | 4 + lib/librte_eal/common/include/rte_lcore.h | 3 +- lib/librte_eal/common/include/rte_service.h | 387 +++++++++++ .../common/include/rte_service_component.h | 144 +++++ lib/librte_eal/common/rte_service.c | 704 +++++++++++++++++++++ lib/librte_eal/linuxapp/eal/Makefile | 1 + lib/librte_eal/linuxapp/eal/eal.c | 18 + lib/librte_eal/linuxapp/eal/eal_thread.c | 9 +- lib/librte_eal/linuxapp/eal/rte_eal_version.map | 23 + test/test/Makefile | 2 + test/test/test_service_cores.c | 599 ++++++++++++++++++ 25 files changed, 2162 insertions(+), 4 deletions(-) create mode 100644 doc/guides/prog_guide/service_cores.rst create mode 100644 lib/librte_eal/common/include/rte_service.h create mode 100644 lib/librte_eal/common/include/rte_service_component.h create mode 100644 lib/librte_eal/common/rte_service.c create mode 100644 test/test/test_service_cores.c -- 2.7.4