From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 2F9F45688 for ; Wed, 2 Sep 2015 17:58:04 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP; 02 Sep 2015 08:58:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,454,1437462000"; d="scan'208,217";a="553919630" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by FMSMGA003.fm.intel.com with ESMTP; 02 Sep 2015 08:58:00 -0700 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 2 Sep 2015 16:57:59 +0100 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.251]) by IRSMSX156.ger.corp.intel.com ([169.254.3.65]) with mapi id 14.03.0224.002; Wed, 2 Sep 2015 16:57:59 +0100 From: "Betts, Ian" To: "dev@dpdk.org" Thread-Topic: [ RFC ] performance thread example Thread-Index: AdDll6rd9m23fGDXThiHqCC7t26VgA== Date: Wed, 2 Sep 2015 15:57:59 +0000 Message-ID: <877C1F8553E92F43898365570816082F35BD1402@IRSMSX103.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] [ RFC ] performance thread example X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:58:05 -0000 Hi Folks, Would welcome feedback on this proposal for an example app to explore perfo= rmance with different threading models. Thanks, Ian Performance thread example application This example will comprise a simple layer 3 forwarding application distribu= ted across multiple threads. It will be possible to configure the application for, and contrast forwardi= ng performance of different threading models, More specifically when the different threads are:- 1. EAL threads running on different physical cores 2. EAL threads running on the same physical core ( multiple lcore per= physical core) 3. Lightweight threads running in an EAL thread on one more physical = cores. Purpose and justification Since dpdk 2.0 it has been possible to assign multiple EAL threads to a phy= sical core ( case 2 above ). Currently no example application has focused on demonstrating the performan= ce constraints of differing threading models. Whilst purpose built applications that fully comprehend the DPDK single thr= eaded programming model will always yield superior performance, the desire to preserve ROI in legacy code written for multithreaded operati= ng environments makes lightweight threads ( case 3 above ) an option worthy of consideration. As well as aiding with legacy code reuse, it is anticipated that lightweigh= t threads will make it possible to scale a multithreaded application with fine granularity allowing an application to more easily t= ake advantage of headroom on EAL cores, or conversely occupy more cores, as dictated by system load. To explore performance with lightweight threads a simple cooperative schedu= ler subsystem is being included in this example application. If the expected benefits and use cases prove to be of value, it is anticipa= ted that this lightweight thread subsystem would become a library in some future DPDK release. Proposed High-Level Solution(s) A layer 3 forwarding application will comprise a number of threads from rx = through tx stages, and will accept command line parameters enabling the assignment of queues to threads, threads to lcores, and lcores to physi= cal cores. In the case that the threads are to be lightweight threads then a lightweig= ht thread scheduler will be run as the main loop of one or more EAL threads. The lightweight thread subsystem will have an API comparable in purpose to = a subset of the equivalent POSIX P-thread functions. Main APIs * Thread control APIs o Lthread_create o Lthread_cancel o Lthread_join o Lthread_detach o Lthread_exit o Lthread_sleep o Lthread_yield o Lthread_set_affinity o Lthread_current * Thread local storage APIs o Lthread_set_data o Lthread_get_data o Lthread_key_create o Lthread_key_delete o Lthread_get_specific o Lthread_set_specific o PER_LTHREAD macros * Sychronization APIs o Lthread_mutex_init o Lthread_mutex_destroy o Lthread_mutex_lock o Lthread_mutex_trylock o Lthread_mutex_unlock o Lthread_cond_init o Lthread_cond_destroy o Lthread_cond_wait o Lthread_cond_signal o Lthread_cond_broadcast * Scheduler control APIs o Lthread_num_schedulers_set o Lthread_active_schedulers o Lthread_run Proposed example format The L-thread packet forwarding application, (and test code) , will be examp= le applications under RTE_SDK/examples/. The L-thread subsystem will be a c= ommon source folder included by these applications. RTE_SDK/examples/lthread RTE_SDK/examples/lthread/common/ RTE_SDK/examples/lthread/l3fwd-lthread/ RTE_SDK/examples/lthread/test/ Ian Betts Intel Shannon Limited Registered in Ireland Registered Office Collinstown Industrial Park, Leixlip, County Kildare Registered Number:308263 Business address: Dromore House, East Park, Shannon, Co. Clare -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the s= ole use of the intended recipient(s). Any review or distribution by others = is strictly prohibited. If you are not the intended recipient, please conta= ct the sender and delete all copies.