From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=z4Oi4fC+MIRd80UmZSQOhsOVYteNu1iFzFzEAnyfcwk=; b=D3CDeGZNi18AL2+1w26j48kZ5VbP3Ms32hCBRhQZ+J8+BVXZjeWHqpOC38/L5zQjAm F+Z+8Qv4hILrdQULWhsQ2k6gcFjpa0WqW+TQMc/urkAgIOYPuDp4/6C690Cjs4zRSdKa WWwJSPPhqX3UPhayHQIiI+DU4jEht7PX2Kv5b4aZgksH4ACpHxN/6CzzjGrX+mBmahTE Vmlv1YQyylgdjPE4ngZKwP89m/eAQyS3nzIqZWGy4hiDlPXYRs4Z7/Yj/ZB4Nd26l+nx 9pyi/VftF+m1YqKTIqGXXysP3SHh8bVin+IexeGQCJVyVw9HMxIJ43NxkocE49hkCQub nZgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=z4Oi4fC+MIRd80UmZSQOhsOVYteNu1iFzFzEAnyfcwk=; b=fbV2qGB1uP0J3P7e4SHXEl9CWFhjIqLzA2vt41BHzBY0MxGT5BatyHGPjTOMYYNIKS oDmT1Ix9O8yotfbiC1vZiL79/cUrlrIpPHCHJCcZRLFP+y+qNgOcI39xuBogFHp591Fi 1lGps1x0lLVpmfRuDcUn7rR23Y/f7iXrOa6SiLxgsqipOwLDdqmBueIBiUrXdr2tW4Lz 7RR6Y3EVJtPqxl+QUaU3U4oBsmw9fCKgGDxXV2wBzkFswoQxXU0wrHv1Oo4Wts2CaNfY p9fKsYTUVxd7X6xmU5v3H9PZO/0vuOk8TVJtb0tpXt1wuycGMj0mk90N18nq7VEkAu5L Lj6w== X-Gm-Message-State: ALoCoQlkyi9PoH3tFZnf+bG1aKcVj6sKQ1xh2Hy5DCxde5vhxYePNi7c2grR/HbM/ND+7mD6haPt X-Received: by 10.98.89.136 with SMTP id k8mr23342276pfj.58.1449252229992; Fri, 04 Dec 2015 10:03:49 -0800 (PST) Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id r79sm18465494pfa.61.2015.12.04.10.03.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2015 10:03:49 -0800 (PST) Date: Fri, 4 Dec 2015 10:03:59 -0800 From: Stephen Hemminger To: Ian Betts Message-ID: <20151204100359.6b966aea@xeon-e3> In-Reply-To: <1449225265-14480-1-git-send-email-ian.betts@intel.com> 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 Subject: Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread 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: Fri, 04 Dec 2015 18:03:50 -0000 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...