From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [RFC PATCH 0/7] support multi-phtread per lcore Date: Thu, 18 Dec 2014 16:11:12 +0100 Message-ID: <5492EE90.4040502@6wind.com> 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> <20141218143225.GA2460@bricha3-MOBL3> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dev-VfR2kkLFssw@public.gmane.org" To: Bruce Richardson , "Walukiewicz, Miroslaw" Return-path: In-Reply-To: <20141218143225.GA2460@bricha3-MOBL3> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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