From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id C979968A1 for ; Wed, 3 May 2017 13:29:16 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP; 03 May 2017 04:29:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,283,1491289200"; d="scan'208";a="852388209" Received: from silpixa00398672.ir.intel.com ([10.237.223.128]) by FMSMGA003.fm.intel.com with ESMTP; 03 May 2017 04:29:13 -0700 From: Harry van Haaren To: dev@dpdk.org Cc: Harry van Haaren , bruce.richardson@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com, narender.vangati@intel.com, jerin.jacob@caviumnetworks.com, gage.eads@intel.com Date: Wed, 3 May 2017 12:29:20 +0100 Message-Id: <1493810961-139469-1-git-send-email-harry.van.haaren@intel.com> X-Mailer: git-send-email 2.7.4 Subject: [dpdk-dev] [RFC] Service Cores concept X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 11:29:17 -0000 This RFC introduces the concept of a service-core. A service core invokes a function when an lcore is required to perform some work. An example use-case is the eventdev; with the octeontx PMD, events are scheduled in the hardware. With the software eventdev PMD an lcore is required to perform this scheduling behaviour. Similar software schemes can be applied for Traffic-Management/QoS for example. The concept is to allow a software function register itself with EAL as a "service", which requires CPU time to perform its duties. Multiple services can be registered in an application, if more than one service exists. The application can retrieve a list of services, and decide how many "service cores" to use. The number of service cores is removed from the application usage, and they are mapped to services based on an application supplied coremask. The application now continues as normal, without having to manually schedule and implement arbitration of CPU time for the SW services. Please note this is an RFC, and API updates to make it cleaner (moving things to private .h files etc) are expected. Think about the concept first - then look at the detail :) This RFC addresses the discussion in this thread (split over two months), and participants of those discussions are on --cc: http://dpdk.org/ml/archives/dev/2017-April/064544.html http://dpdk.org/ml/archives/dev/2017-May/065176.html Regards, -Harry Harry van Haaren (1): RFC: service core concept header implementation lib/librte_eal/common/include/rte_service.h | 211 ++++++++++++++++++++++++++++ 1 file changed, 211 insertions(+) create mode 100644 lib/librte_eal/common/include/rte_service.h -- 2.7.4