From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0081.outbound.protection.outlook.com [104.47.41.81]) by dpdk.org (Postfix) with ESMTP id 9F1F0330D for ; Thu, 4 May 2017 08:36:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Lvvt9Zi13HjW5b8sDK626cVUlrN1qMNwqZkiO2NslxQ=; b=ecbyixg57J8g8U9Q81kDukgfKNAzd20jytuklB9l07BPFXMCfeefnVQX6rnp3qN78uyxIEEaZWv9I0C4YHbSulMFRTrzBDGUq2GlWUkutREEsjjKLupVHCQw4p6fH0bzRBWs36QBFPLfulH6D+Vp66dA4WsWermkzpfLes+aJxY= Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=caviumnetworks.com; Received: from jerin (111.93.218.67) by BY1PR0701MB1721.namprd07.prod.outlook.com (10.162.111.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Thu, 4 May 2017 06:36:13 +0000 Date: Thu, 4 May 2017 12:05:56 +0530 From: Jerin Jacob To: Harry van Haaren Cc: dev@dpdk.org, bruce.richardson@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com, narender.vangati@intel.com, gage.eads@intel.com Message-ID: <20170504063543.GA2794@jerin> References: <1493810961-139469-1-git-send-email-harry.van.haaren@intel.com> <1493810961-139469-2-git-send-email-harry.van.haaren@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1493810961-139469-2-git-send-email-harry.van.haaren@intel.com> User-Agent: Mutt/1.8.2 (2017-04-18) X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: BMXPR01CA0033.INDPRD01.PROD.OUTLOOK.COM (10.174.214.19) To BY1PR0701MB1721.namprd07.prod.outlook.com (10.162.111.140) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d3f6a03b-fff4-47f7-3e3b-08d492b7dddf X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:BY1PR0701MB1721; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1721; 3:2yzGxuFBNUXCJVELpnN2cr8VrPYLlBmJZazDrs1v/PJFzBP4kFLq481TcJ2qd5ipYSjGcaGdwkUGInJTcmM5mJzotHC9/nn3uWeAz2GJuNp7wQFQn+nLNuUN307rrWaVFt1GXM1HPG9TRfV/lh5NwpDVTn3pyRcjhMdGiDOXtPhGZeLoEZ1OF6JGIP2dti2W9Hjwg7ujFV1rCpAod3eS2Vzu8D9Xj4cOpRn95VfLB87RLc14vRFgkuBckeBBiuTbzLrLr1Pw6X+TEauqxcEPK8N9OAJHH2wYeuI3p6WYSRPbtB/TyukVT6xLSVJZRF7rmSz877NFvn8x/qUzE26RoA==; 25:e6JLYsSEER0a43WkxzYPk1lBwaSqk2Br37KoRb3nCfCNkyMp6LGnAHfE421VuUyR/n3XEpmflAM3SDYMuQ4oUO9yiYs0Z1whUX01B2jw54WW0mgzFruT7Oxk1mMApXoMkHDxy7lXdjE4wNrCOpq+1qJ33m2JEWs1kxJbzCmln+qxpDhFTWcY1v6SCGYXFoTxl8T1m+/2QvvwWqNj55P67mgCVVDyZWlt19MHIbcfGzKFfAGw8eUPoJpVEIt+miZc3wO/9MTMJbCOwd14E8wZmMooj1ckSrsWsW0Lcl+bkHrTQg4h6OUDbrjzXO0xIAOwN3JLtUnQcy51Ubh+XH4h/ZjVnGvWwBjrVuCa5yjk160Ps7A6WZibWWf3UE+fL4bUwbH3myqHlisDov2zqFVbBwB3A6JrxX9KkXI95JjeecllicuEX/pOhIsXXsGRZvmrelg2FJBRfsMX1xuKXd3TCQ== X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1721; 31:KslIwR4z6ND6dtmt2PNO6YwKyl6jPCDrbwKeTzrvLL2EC9XvINlYL3sfL8mSknfnpkI2nD3RwJN8FhC5QT7AseCkR79tRHDlRk1L+VsXYaK7dSM8xISlJVmpR69v30PmZ3eisDSYgrQ5ctdPfungD1t3lOYVb09xffFt2RytO68sbFEP1gwJtEtDi7+0d6HWe/bBKc1Lm81SXh1+/moJCVT9UDBVXU8aQLT2du8mDkTdjEKia1vydKrwSAhhZ2hp+dob8bQ7zRXSkCbEaILuVVcBj0g6brb90797PubU2to=; 20:VsIsnOeYt7JBPu6ZCFNhzwlCfPK+gwFzyQsxD0ln3EGhtHCwnK41G8Q2yKGBGRv/njJFdk2uYTNqykTIBLffavuSqxnRLRdk62VwxZfomX3d5zLyWLKQ8Tx4vRPZyLWnYuWyJHGKR35Mj38ONWDPrKRv04lYw0Ab4np4DKU/hUv8dDjnVks9qiz4SwnPOqw7vHAN8Q4VtQOOPZbvFRbS/aQgoFYjEKDRfbUWQFIdzjbomxIJe4JogfpLG7vGzWHJoQggarBanWxqFkG8lpD+7ajjsOC6jOjnJ+Dv2PytJce6kkM5ZQ8gHO6lVfhFBVYSm9zSLPIeQlxYVq379ugtPgn2aCwKL1mOCeMHc52V2l/AcI/809XY1diGiJFi1t7i7dJKa5vjdsFqOKp5MZbGBs7qOs3n7CyqVtGs1Dx5jH1xB2+han/AnJae9Eoys7ZCXZFaEEvAxVwTrcbN5bLBQMkuxcBbA5I9emO44wB3WhEk6LYYs5wiM2hdzFOU1xGe6gRa9GVawC2X05T1Zk3/bGZOWpPt8iSRcJMz0u7u0Eeh2UDTk+m2CFcwMmx4ensS0VWnRx1gl2VDpyi54J8n14ItQ8XUxAbjMS6cC3l5rMI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(35073007944872)(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(6072148); SRVR:BY1PR0701MB1721; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0701MB1721; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1721; 4:fC46IkeAh9r9DJUhx5NcTfXVfErBTKbCrlPMJXmYsodod2NLv3j6cpIgpRbBW4JWLit/H7flptmRGfrhaUBYpiSOtGRbwQZ31YyyfRwty7QD6+oH9rY4BBbfls+H8emhqX0z6S1DfrxfqLG07L+9SJz8q5pNoWLPxT6svF5tL7JjhyJ8UnC3KpwvbPHam4POUnbvmxhw/90R9zzp/TLI87XImOnTBHwqbju4iHPs9o6k6LCWNSCdtIJh+98etlNUBWjCOak9EybDJtv6mHzIwQRHzb1ZY27V6DQZvsHfZsB6HGdgxNEdLIUhCH21P1wyTuoAAcYGimp1t0SynlzBiLSHemxByhJmpZ9K8U5c2Vyv7JbjdaQFCVvIT2gibUheGxINLqNtb+i3W3M83TxaP6nFeIlBb0ObOgA25sbEoseLsTvUgngAP0mtnXXXWhc/SRbxHG3fVk19Ijj4zvyCSf3UsYG+a6FlPpcAphs+fZ0+FwbUCGKVJ2DjEBaPqlgWTGlLq5na1oBrlcnZdYtXhVjKjVKT3hCT1UZX2uW53ScEOnYc9hfhK3FW5co/EzDa0bTOD3dGpnICy1fVdtOQXYiNbZr5gwMYAl0ZQAkBSAP5tcP7zRx85vwpuhMB27yxmyhs1OyEUptCgOqsH+DWgFEs9zmWE+bMbsi4Y/SjnYynuWFQyVT0536kUd15qX3xLORDRigG+S1I8ipya+8pwHOJJQVUOEYxaAaPI/KPmqtbzEIIWGTLj/i8MgPj4YbG8oWueaaPEonvfhdp4zELS3pBfLrRxu/2Skc0M34soprqCy3iBOV2R2ieBB4OvJNuttwNk2ey7yp3CxJXlSmvJNDo2MKa9DYqqfbpv6h44R30FcV2nbKkNo83uS5YC6M9 X-Forefront-PRVS: 02973C87BC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(13464003)(9686003)(4001350100001)(6246003)(38730400002)(1076002)(5660300001)(23726003)(110136004)(2950100002)(2906002)(42882006)(55016002)(6496005)(6116002)(478600001)(6916009)(53936002)(50986999)(76176999)(5009440100003)(81166006)(50466002)(54356999)(229853002)(25786009)(8676002)(189998001)(83506001)(4326008)(33656002)(6666003)(8656002)(3846002)(42186005)(47776003)(305945005)(33716001)(66066001)(7736002)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0701MB1721; H:jerin; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0701MB1721; 23:tcgsEA4nbm9kDZxNffiW/uEp9JDqN9ZzZ0qRAfD?= =?us-ascii?Q?nv23cgcuP4zWmtRFCkjOrUgWHoD6AvkqJvNNGd6SMqhc7W8pXQVwB9EtcNoH?= =?us-ascii?Q?e1iwF8WFC+4sl8oObyFxvIl0TtebWn1fAfRWMnp0WK/K35DGw5V2EZNXMmi0?= =?us-ascii?Q?eHRXaMhRr9MlQujqItNd0JQ9EMmHBvfFECtIk/DzS6q10AQV6jkHGP77V0G3?= =?us-ascii?Q?a5Vix/WDqTZVILWVV30mv9FBdVoBFQ/UgtAXInlB+2ar9uuSSY33aWXTG9ed?= =?us-ascii?Q?Ga5WqkL+IkvVUKyvKNuDFY6Oow5lfg9IvYQ2w2LEAH+ohRJIVxz8Bzyro6Tz?= =?us-ascii?Q?0K68MSXHrF0tPxD+/huvxRAYct+LoSsZJVe3QKzYKm1MBF+g1oB+67UDExwg?= =?us-ascii?Q?ROFrF0gmMcYlurCFR14dUhgbvBkIGU0nuBt21l3xCa4AjOYGsWhf0sXePtUu?= =?us-ascii?Q?c/dIMw5qyj0SnDjbM4s7zj963lNVkXDo1lwFDYu3etS8KQ4CHOebeDSkjlSL?= =?us-ascii?Q?BRoepwhePI8TtYl1hi/Xtk0qNo4LLD/0TZeDk+VJ0WY+TmxDi1t0IH/60yyp?= =?us-ascii?Q?T6a0nXs7dSk0eDEzGvOPMFGfhVL8TCCOVaQRdpnPduYu8zTBP/TgRgUEC2Mv?= =?us-ascii?Q?ZlfXzU8o/X6FzV/Dg2LZ4LI252uKE3l3lhAB/YC7riTNip53LGGSPwXJcJRU?= =?us-ascii?Q?rwgT9B7SrCgWAcu6B180zQde6alSwkee94qiUmLU4JSNrpFSEPb1ejK+fooL?= =?us-ascii?Q?9LVtqNJ9EiRXnSW2M0YCIQRRX6OSoEsPuxfYsoJk5Gp99kzo3Wkq/8K/tqtN?= =?us-ascii?Q?c93KrkqWQ7Xk3RplBEaOWJL4b2yAm8UuByjdo3Zlb9ufIX43GPh+aJz3jYMi?= =?us-ascii?Q?AI5rFZmtKad7dw1hq15N7yc6uml6+Bi0qzmDMPDr/dFN4oKZy2QRzEegwOVZ?= =?us-ascii?Q?qvhDhp3aMeS+Ah1a8upKdbUkatDkg64Ypy48sSK07RkgJxsgRakrvFiEQIfB?= =?us-ascii?Q?XTbh16CWvXhxsd/AZZ2Upwt/DHaBhsIyXfQ6oxsrg649+yGtBHV6PTFy9tgu?= =?us-ascii?Q?fdEC82oW9aBzi539bNANMtU+BnsMwYpFcoJOP/p9huevl2hJvCPmD/2mG5cZ?= =?us-ascii?Q?zQ+16Yo930i8GuArlJXMRkVdzuZ1qIRgCZCAB3yLABQmXz04E+3GP5ADLUsm?= =?us-ascii?Q?nrBIQnktovEfyiXC8ME3l1Fqlo3ALpFPopv0q?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1721; 6:RT05gFW48HuA1vNDuFJJUqZoqzfNJ4/ErFaeP1vHaTn0NG7vTTE4nmOrp/cQUCngpbzKhBugo4v1sCLXyT4zl1T+a9HSLsaXzreZ4W5nALJK+s32l1vJ6zErw/M5sXayR0q8he7fWNfmFOJA90AMhE1T/6Fqf1BOBzQaIxASwRV0y16emLy4kFtm2bPPB+Lrm7c6fD9K7pLI6HzaVVqltWps+lrDeXuspEuEPlKQiDllaKFUGIRp8zgCdCz9VAVQFzlEZA0G1y0T5ehHbXuuqiQkHczXnpex02vnKIMNuNUpS0QE8OB5BjVuQYN5IZ8lu6BwzWfSur4SVaithL5f+Tx10FqtWnZSDgj46AVu2nMTP2Sljt9S3aTZE0wUr2f6C24zd1I5YXhVnIMTpS1b+J2YzJqcU2GthRw7chRNGdAcA/mlDhKpC2d8trHLoO9vNIafvriXdFC0Nx9kMnoujPkp6kSRi92DISJYQit4dszgsN3YpN0Pp9isg2e/azfLqdYp/JfJwUupj2SX+awOPw==; 5:USz3KnnnoIkh+TCINia2WGcwDXTTvhHFDgK6el3yFgLaScaUEl01H/i+EuYhSymwzP6QzM/zVNyDGA2I78kd0g5B9wIjxZSQ6ePcZdUSbN/gDrWVgasHkb3ikhG2TrR+qTfHixZ+8IHk5oJrDqlo5w==; 24:eEek3SUtQYFPaxJZqBpGZbB+p5ZkbhPW2ZtLCqvjkYcdA51YzM5iZmHosq0VrXp0TDUj31VzzvQMWsFiARDCj2Dsy6muwcmAq5BKkDr9nl8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1721; 7:3iqyubHs8cPdAS/TKOrcyMHMlewyeKSCv+d7h5nyBVMv7YlWXbRLunJrtBHB4Clt3uZdAsFeUU+pJ55545UxDdnuZLywUX56+Ry5yEWHNfX0Jv7gX/Htawi4TzSIWeebgT1jsUw3S1Glvqy5gfGQr58SSYr6118gd3FEcOOe+fqYB0h73o2DLbDGBLIbeB7fgmTGZZIEwp5GgtDhUVhAbHFUXezpG34XDPYLjVyl97wBVIvqSoeQJewDHuH6XdPeSBtj6zxGxmJk5tUYKAi2sXo+89umo5jQV2E5Pj6wC+J/67V4f94GsaQjXT4vwL86DJKVaQ16PCB+o7jStgeN+w== X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2017 06:36:13.5123 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0701MB1721 Subject: Re: [dpdk-dev] [RFC] service core concept header implementation 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: Thu, 04 May 2017 06:36:20 -0000 -----Original Message----- > Date: Wed, 3 May 2017 12:29:21 +0100 > 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 > Subject: [RFC] service core concept header implementation > X-Mailer: git-send-email 2.7.4 Hi Harry, Overall it looks good. Some initial comments > > This patch adds a service header to DPDK EAL. This header is > an RFC for a mechanism to allow DPDK components request a > callback function to be invoked. > > The application can set the number of service cores, and > a coremask for each particular services. The implementation > of this functionality in rte_services.c (not completed) would > use atomics to ensure that a service can only be polled by a > single lcore at a time. single lcore at a time "if multipthread_capable flag is not set". Right? > > Signed-off-by: Harry van Haaren > --- > 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 > > diff --git a/lib/librte_eal/common/include/rte_service.h b/lib/librte_eal/common/include/rte_service.h > new file mode 100644 > index 0000000..cfa26f3 > --- /dev/null > +++ b/lib/librte_eal/common/include/rte_service.h > @@ -0,0 +1,211 @@ > +/* > + * BSD LICENSE > + * > + * Copyright(c) 2017 Intel Corporation. All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * > + * * Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer. > + * * Redistributions in binary form must reproduce the above copyright > + * notice, this list of conditions and the following disclaimer in > + * the documentation and/or other materials provided with the > + * distribution. > + * * Neither the name of Intel Corporation nor the names of its > + * contributors may be used to endorse or promote products derived > + * from this software without specific prior written permission. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR > + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT > + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT > + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE > + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#ifndef _RTE_SERVICE_H_ > +#define _RTE_SERVICE_H_ > + > +/** > + * @file > + * > + * Service functions > + * > + * The service functionality provided by this header allows a DPDK component > + * to indicate that it requires a function call in order for it to perform > + * its processing. > + * > + * An example usage of this functionality would be a component that registers > + * a service to perform a particular packet processing duty: for example the > + * eventdev software PMD. At startup the application requests all services > + * that have been registered, and the app decides how many cores will run the s/app/application > + * required services. The EAL removes these number of cores from the available > + * runtime cores, and dedicates them to performing service-core workloads. The > + * application has access to the remaining lcores as normal. > + * > + * An example of the service core infrastructure with an application > + * configuring a single service (the eventdev sw PMD), and dedicating one core > + * exclusively to run the service would interact with the API as follows: > + * > + * 1. Eventdev SW PMD calls *rte_eal_service_register*, indicating that it > + * requires an lcore to call a function in order to operate. EAL registers > + * this service, but performs no other actions yet. > + * > + * 2. Application calls *rte_eal_service_get*, allowing EAL to provide it > + * with an array of *rte_service_config* structures. These structures > + * provide the application with the name of the service, along with > + * metadata provided by the service when it was registered. > + * > + * 3. The application logic iterates over the services that require running, > + * and decides to run the eventdev sw PMD service using one lcore. > + * > + * 4. The application calls *rte_eal_service_use_lcore* multiple times, once > + * for each lcore that should be used as a service core. These cores are > + * removed from the application usage, and EAL will refuse to launch > + * user-specified functions on these cores. > + * > + * 5. The application calls *rte_eal_service_set_coremask* to set the coremask > + * for the service. Note that EAL is already aware of ALL lcores that will > + * be used for service-core purposes (see step 4 above) which allows EAL to > + * error-check the coremask here, and ensure at least one core is going to > + * be running the service. Regarding step 4 and 5, It looks like, a) The lcore_id information is duplicate in step 4 and 5. b) On rte_eal_service_set_coremask() failure, you may the need inverse of rte_eal_service_use_lcore()(setting back to worker/normal lcore) But I understand the need for step 5. How about changing the (4) and (5) as step 4) rte_eal_service_set_coremask step 5) rte_eal_service_apply(void)(or similar name) for error check and ensure at least on core is going to be running the service. > + * > + * 6. The application now calls remote_launch() as usual, and the application > + * can perform its processing as required without manually handling the > + * partitioning of lcore resources for DPDK functionality. > + */ > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > +#include > + > +#define RTE_SERVICE_NAMESIZE 32 > + > +/** > + * Signature of callback back function to run a service. > + */ > +typedef void (*rte_eal_service_func)(void *args); > + > +struct rte_service_config { I think, better name is rte_service_spec or something similar > + /* name of the service */ > + char name[RTE_SERVICE_NAMESIZE]; > + /* cores that run this service */ If I understand it correctly, a) Its for NUMA b) Basically advertising the core(s) which capable or preferred to run the service. Not the number of cores "required" to run the service. if so, update the comments > + uint64_t coremask; 64bits are not enough to represent the coremask. May be array of uint64_t or array of int can be used. I think, latter is more inline with exiting eal scheme > + /* when set, multiple lcores can run this service simultaneously without > + * the need for software atomics to ensure that two cores do not > + * attempt to run the service at the same time. > + */ > + uint8_t multithread_capable; > +}; > + > +/** @internal - this will not be visible to application, defined in a seperate > + * rte_eal_service_impl.h header. The application does not need to be exposed > + * to the actual function pointers - so hide them. */ > +struct rte_service { > + /* callback to be called to run the service */ > + rte_eal_service_func cb; > + /* args to the callback function */ > + void *cb_args; > + /* configuration of the service */ > + struct rte_service_config config; > +}; > + > +/** > + * @internal - Only DPDK internal components request "service" cores. remove @internal here > + * > + * Registers a service in EAL. > + * > + * Registered services' configurations are exposed to an application using > + * *rte_eal_service_get_all*. These services have names which can be understood > + * by the application, and the application logic can decide how to allocate > + * cores to run the various services. > + * > + * This function is expected to be called by a DPDK component to indicate that > + * it require a CPU to run a specific function in order for it to perform its > + * processing. An example of such a component is the eventdev software PMD. > + * > + * The config struct should be filled in as appropriate by the PMD. For example > + * the name field should include some level of detail (e.g. "ethdev_p1_rx_q3" > + * might mean RX from an ethdev from port 1, on queue 3). > + * > + * @param service > + * The service structure to be registered with EAL. > + * > + * @return > + * On success, zero > + * On failure, a negative error > + */ > +int rte_eal_service_register(const struct rte_service *service); > + > +/** > + * Get the count of services registered in the EAL. > + * > + * @return the number of services registered with EAL. > + */ > +uint32_t rte_eal_service_get_count(); > + > +/** > + * Writes all registered services to the application supplied array. > + * > + * This function can be used by the application to understand if and what > + * services require running. Each service provides a config struct exposing > + * attributes of the service, which can be used by the application to decide on > + * its strategy of running services on cores. > + * > + * @param service_config param [out] service_config. > + * An array of service config structures to be filled in > + * > + * @param n > + * The size of the service config array > + * > + * @return 0 on successful providing all service configs > + * -ENOSPC if array passed in is too small > + */ > +int rte_eal_service_get_all(const struct rte_service_config *service_config, > + uint32_t n); > + > +/** > + * Use *lcore_id* as a service core. > + * > + * EAL will internally remove *lcore_id* from the application accessible > + * core list. As a result, the application will never have its code run on > + * the service core, making the service cores totally transparent to an app. > + * > + * This function should be called before *rte_eal_service_set_coremask* so that > + * when setting the core mask the value can be error checked to ensure that EAL > + * has an lcore backing the coremask specified. > + */ > +int rte_eal_service_use_lcore(uint16_t lcore_id); > + > +/** > + * Set a coremask for a service. > + * > + * A configuration for a service indicates which cores run the service, and > + * what other parameters are required to correclty handle the underlying device. > + * > + * Examples of advanced usage might be a HW device that supports multiple lcores > + * transmitting packets on the same queue - the hardware provides a mechanism > + * for multithreaded enqueue. In this case, the atomic_ Missing text after atomic_. missing @param > + * > + * @return 0 Success > + * -ENODEV Device with *name* does not exist > + * -ENOTSUP Configuration is un-supported > + */ > +int rte_eal_service_set_coremask(const char *name, uint64_t coremask); > + > + > +#ifdef __cplusplus > +} > +#endif > + > + > +#endif /* _RTE_SERVICE_H_ */ > -- > 2.7.4 >