From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gemini.bisdn.de (gemini.bisdn.de [212.91.241.169]) by dpdk.org (Postfix) with ESMTP id 447A26828 for ; Mon, 7 Apr 2014 15:55:57 +0200 (CEST) Received: from [172.16.250.161] (unknown [185.27.182.30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by gemini.bisdn.de (Postfix) with ESMTPSA id DFFAB80149; Mon, 7 Apr 2014 15:55:55 +0200 (CEST) Message-ID: <5342AEE4.6090904@bisdn.de> Date: Mon, 07 Apr 2014 15:57:56 +0200 From: Marc Sune User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: "Richardson, Bruce" References: <53429F2F.7050602@bisdn.de> <59AF69C657FD0841A61C55336867B5B01A9F91D0@IRSMSX103.ger.corp.intel.com> In-Reply-To: <59AF69C657FD0841A61C55336867B5B01A9F91D0@IRSMSX103.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "" Subject: Re: [dpdk-dev] RTE_EAL on single core CPUs 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, 07 Apr 2014 13:55:57 -0000 Dear Bruce, Thank you for the quick reply, you are indeed right. In fact the problem is much more simple than that, now that I realise. Our application must have one (or more) threads which do background tasks aside from packet processing (one of them is actually controlling the I/O), and with multi-core architectures we were sacrifising core0 for such purpose. The question now would be how is the appropriate way to treat this situation with DPDK; a) First creating a thread before calling rte_eal_init(): main thread -> pthread_create() I/O thread -> call rte_eal_init() (from I/O thread? main thread? irrelevant?) -> ... -> I/O thread calls rte_eal_remote_launch() to launch itself b) Create it after: main thread -> rte_eal_init() call from main thread -> pthread_create() I/O thread -> ... -> I/O thread calls rte_remote_launch() to launch itself I guess option a) would be more suitable, is it? thank you and regards marc On 07/04/14 14:55, Richardson, Bruce wrote: >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Marc Sune >> Sent: Monday, April 07, 2014 1:51 PM >> To: >> Subject: [dpdk-dev] RTE_EAL on single core CPUs >> >> Dear all, >> >> I was preparing a development machine (kvm - qemu) with a single core, and stumbled with >> what appears to be a limitation with EAL [1]. >> The VM is setup emulating a SandyBridge CPU but with a single CPU and running >> 1.6.0 branch HEAD (perhaps this is the problem?¿). >> >> I was also interested in this particular setup, because we haven't yet tried our application >> with some Atom equipment we have here, but we need to make it run also there. >> >> Any ideas? I am probably missing something really fundamental here. > Hi Marc, > > I think in your case you've hit more a limitation of the particular app, rather than one for the EAL. L2fwd requires more than a single core to run, but you can easily write applications that can handle packets from multiple ports using a single core. > Where you may hit issues, though, is that you cannot isolate the single core cpu from the linux kernel, so you may need to ensure you have enough buffering throughout the app to avoid packet loss when the kernel interrupts you to do its own house-keeping tasks. > > Regards, > /Bruce >