From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH v8 0/4] examples: add performance-thread Date: Fri, 4 Dec 2015 10:03:59 -0800 Message-ID: <20151204100359.6b966aea@xeon-e3> References: <1449159683-7092-3-git-send-email-ian.betts@intel.com> <1449225265-14480-1-git-send-email-ian.betts@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Ian Betts Return-path: Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com [209.85.192.171]) by dpdk.org (Postfix) with ESMTP id 980E391FC for ; Fri, 4 Dec 2015 19:03:50 +0100 (CET) Received: by pfnn128 with SMTP id n128so29516609pfn.0 for ; Fri, 04 Dec 2015 10:03:50 -0800 (PST) In-Reply-To: <1449225265-14480-1-git-send-email-ian.betts@intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, 4 Dec 2015 10:34:21 +0000 Ian Betts wrote: > This patchset comprises a layer 3 forwarding derivative intended to > facilitate characterization of performance with different > threading models, specifically:- > > 1. EAL threads running on different physical cores > 2. EAL threads running on the same physical core > 3. Lightweight threads running in an EAL thread > > Purpose and justification > > Since dpdk 2.0 it has been possible to assign multiple EAL threads to > a physical core ( case 2 above ). > Currently no example application has focused on demonstrating the > performance constraints of differing threading models. > > Whilst purpose built applications that fully comprehend the DPDK > single threaded programming model will always yield superior > performance, the desire to preserve ROI in legacy code written for > multithreaded operating environments makes lightweight threads > (case 3 above) worthy of consideration. > > As well as aiding with legacy code reuse, it is anticipated that > lightweight threads will make it possible to scale a multithreaded > application with fine granularity allowing an application to more > easily take 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 > scheduler subsystem is being included in this example application. > If the expected benefits and use cases prove to be of value, it is > anticipated that this lightweight thread subsystem would become a > library in some future DPDK release. > > Changes in this version > * remove ASM implementation of atomic64_xchg in favor > of builtin __sync_lock_test_and_set() Looks useful, but this needs more discussion. Maybe it should be a separate library not tied into DPDK so it gets wider use and testing? Also what are the limitations? What if an lthread did a system call? What about interaction with rte_poll? Earlier attempts at lightweight threading (fibers) would be worth looking into. http://c2.com/cgi/wiki?CooperativeThreading Intel Thread Building Blocks IBM NGPT (now defunct) There lots of hidden gotcha's here, like preemption (or not), and limitations on interactions with other libraries. Intel may have some milestone to get it into DPDK 2.2 but really this seems too late...