From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by dpdk.org (Postfix) with ESMTP id C23649634 for ; Mon, 22 Dec 2014 19:29:02 +0100 (CET) Received: by mail-pa0-f51.google.com with SMTP id ey11so6379571pad.38 for ; Mon, 22 Dec 2014 10:29:02 -0800 (PST) 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=BQNTlNy2XmNvJ7zPrzZ37NouuJon1Id+lWj+bD2hq5g=; b=WEAVWffhGTNyAGh7NSdMBNpdqlJJmQEhERVjiQZfojfnkT8ZAXo8aRJrUCrQJrn/GI zbQSBrMrExu13jJW1kWqKMq7GKF9zZ58W1uFZnXFgDxqaAtarkTLZDTZGLEtHXI/QlnQ 5MuQZdIP/eJddSg8klpLzeef5UemyEUASlAnULaYWO19MfG/zLG4NTE1tTwujr6rYp52 DkEshQTZ73q2BBoz3jM/ehLYeFS1krB+h5FMOaRdUjw/lRBBGUs9KRhx6beA1ia3YzBB F1RGy52mK+B7+dl2WpaqpZaN1FIXUNV2wz/D4SGXq1mxLOQOdhPGOt4Ywd4uxYgTclxe L+UQ== X-Gm-Message-State: ALoCoQnCCn1YsoktFLbh5lcLDcpnO8LP7tf5Tsttye/cdvx6Y86sshWBz0gnHtHML8c4gJ1H0qrL X-Received: by 10.66.102.41 with SMTP id fl9mr37356983pab.7.1419272941884; Mon, 22 Dec 2014 10:29:01 -0800 (PST) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by mx.google.com with ESMTPSA id v3sm17891294pdf.22.2014.12.22.10.28.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Dec 2014 10:29:01 -0800 (PST) Date: Mon, 22 Dec 2014 10:28:52 -0800 From: Stephen Hemminger To: Bruce Richardson Message-ID: <20141222102852.7e6d5e81@urahara> In-Reply-To: <20141222094603.GA1768@bricha3-MOBL3> References: <1418263490-21088-1-git-send-email-cunming.liang@intel.com> <7C4248CAE043B144B1CD242D275626532FE15298@IRSMSX104.ger.corp.intel.com> <7C4248CAE043B144B1CD242D275626532FE232BA@IRSMSX104.ger.corp.intel.com> <7C4248CAE043B144B1CD242D275626532FE27C3B@IRSMSX104.ger.corp.intel.com> <20141219100342.GA3848@bricha3-MOBL3> <20141222094603.GA1768@bricha3-MOBL3> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore 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: Mon, 22 Dec 2014 18:29:03 -0000 On Mon, 22 Dec 2014 09:46:03 +0000 Bruce Richardson wrote: > On Mon, Dec 22, 2014 at 01:51:27AM +0000, Liang, Cunming wrote: > > ... > > > I'm conflicted on this one. However, I think far more applications would be > > > broken > > > to start having to use thread_id in place of an lcore_id than would be broken > > > by having the lcore_id no longer actually correspond to a core. > > > I'm actually struggling to come up with a large number of scenarios where it's > > > important to an app to determine the cpu it's running on, compared to the large > > > number of cases where you need to have a data-structure per thread. In DPDK > > > libs > > > alone, you see this assumption that lcore_id == thread_id a large number of > > > times. > > > > > > Despite the slight logical inconsistency, I think it's better to avoid introducing > > > a thread-id and continue having lcore_id representing a unique thread. > > > > > > /Bruce > > > > Ok, I understand it. > > I list the implicit meaning if using lcore_id representing the unique thread. > > 1). When lcore_id less than RTE_MAX_LCORE, it still represents the logical core id. > > 2). When lcore_id large equal than RTE_MAX_LCORE, it represents an unique id for thread. > > 3). Most of APIs(except rte_lcore_id()) in rte_lcore.h suggest to be used only in CASE 1) > > 4). rte_lcore_id() can be used in CASE 2), but the return value no matter represent a logical core id. > > > > If most of us feel it's acceptable, I'll prepare for the RFC v2 base on this conclusion. > > > > /Cunming > > Sorry, I don't like that suggestion either, as having lcore_id values greater > than RTE_MAX_LCORE is terrible, as how will people know how to dimension arrays > to be indexes by lcore id? Given the choice, if we are not going to just use > lcore_id as a generic thread id, which is always between 0 and RTE_MAX_LCORE > we can look to define a new thread_id variable to hold that. However, it should > have a bounded range. > From an ease-of-porting perspective, I still think that the simplest option is to > use the existing lcore_id and accept the fact that it's now a thread id rather > than an actual physical lcore. Question is, is would that cause us lots of issues > in the future? > > /Bruce The current rte_lcore_id() has different meaning the thread. Your proposal will break code that uses lcore_id to do per-cpu statistics and the lcore_config code in the samples. q