From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id 160537E7C
 for <dev@dpdk.org>; Thu, 18 Dec 2014 16:11:30 +0100 (CET)
Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214]
 helo=[192.168.0.10])
 by mail.droids-corp.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128)
 (Exim 4.80) (envelope-from <olivier.matz@6wind.com>)
 id 1Y1cmm-0003Ti-6b; Thu, 18 Dec 2014 16:14:49 +0100
Message-ID: <5492EE90.4040502@6wind.com>
Date: Thu, 18 Dec 2014 16:11:12 +0100
From: Olivier MATZ <olivier.matz@6wind.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Bruce Richardson <bruce.richardson@intel.com>, 
 "Walukiewicz, Miroslaw" <Miroslaw.Walukiewicz@intel.com>
References: <1418263490-21088-1-git-send-email-cunming.liang@intel.com>
 <7C4248CAE043B144B1CD242D275626532FE15298@IRSMSX104.ger.corp.intel.com>
 <D0158A423229094DA7ABF71CF2FA0DA31188B881@shsmsx102.ccr.corp.intel.com>
 <7C4248CAE043B144B1CD242D275626532FE232BA@IRSMSX104.ger.corp.intel.com>
 <D0158A423229094DA7ABF71CF2FA0DA31188C928@shsmsx102.ccr.corp.intel.com>
 <7C4248CAE043B144B1CD242D275626532FE27C3B@IRSMSX104.ger.corp.intel.com>
 <20141218143225.GA2460@bricha3-MOBL3>
In-Reply-To: <20141218143225.GA2460@bricha3-MOBL3>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Dec 2014 15:11:30 -0000

Hi,

On 12/18/2014 03:32 PM, Bruce Richardson wrote:
> On Thu, Dec 18, 2014 at 12:20:07PM +0000, Walukiewicz, Miroslaw wrote:
>> I have another question regarding your patch.
>>
>>  Could we extend values returned by rte_lcore_id() to set them per thread (really the DPDK lcore is a pthread but started on specific core) instead of creating linear thread id. 
>>
>> The patch would be much simpler and will work same way. The only change would be extending rte_lcore_id when rte_pthread_create() is called. 
>>
>> The value __lcore_id has really an attribute __thread that means it is valid not only per CPU core but also per thread.
>>
>> The mempools, timers, statistics would work without any modifications in that environment.
>>
>>  I do not see any reason why old legacy DPDK applications would not work in that model. 
>>
>> Mirek
> 
> Definite +1 here. 

One remark though: it looks that the rte_rings (and therefore the
rte_mempools) are designed with the assumption that the execution
units are alone on their cores.

As explained in [1], there is a risk that a pthread is interrupted
by the kernel at a bad moment. Therefore another thread can be
blocked, spinning on a variable to change its value.

The same could also occurs with spinlocks which are not designed
to wakeup another pthread when the lock is held (like pthread_locks).

And finally, having several pthreads per core implies that the
application should be designed with large queues: if a pthread is
not scheduled during 10ms, it represents 100K packets at 10M PPS.

I don't say it's impossible to do it, but I think it's not so
simple :)

Regards,
Olivier

[1] http://dpdk.org/ml/archives/dev/2013-November/000714.html