DPDK patches and discussions
 help / color / mirror / Atom feed
From: Marc Sune <marc.sune@bisdn.de>
To: "Richardson, Bruce" <bruce.richardson@intel.com>
Cc: "<dev@dpdk.org>" <dev@dpdk.org>
Subject: Re: [dpdk-dev] RTE_EAL on single core CPUs
Date: Mon, 07 Apr 2014 15:57:56 +0200	[thread overview]
Message-ID: <5342AEE4.6090904@bisdn.de> (raw)
In-Reply-To: <59AF69C657FD0841A61C55336867B5B01A9F91D0@IRSMSX103.ger.corp.intel.com>

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: <dev@dpdk.org>
>> 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
>

      reply	other threads:[~2014-04-07 13:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-07 12:50 Marc Sune
2014-04-07 12:55 ` Richardson, Bruce
2014-04-07 13:57   ` Marc Sune [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5342AEE4.6090904@bisdn.de \
    --to=marc.sune@bisdn.de \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).