All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney@caviumnetworks.com>
To: linux kernel <linuxk3rnel@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mips <linux-mips@linux-mips.org>
Subject: Re: Feasibility study: Linux on core 0, using other cores as worker cores. Octeon II
Date: Tue, 19 May 2009 09:43:25 -0700	[thread overview]
Message-ID: <4A12E1AD.6000302@caviumnetworks.com> (raw)
In-Reply-To: <29f1ba300905190458y44c8aadeuc8ff914e09105a09@mail.gmail.com>

linux kernel wrote:
> Hi,
> 
> This might seem as an unusal feasibility question, but I would like to
> discuss this here at LKML to hear you views on this matter.
> The idea would be to build a IBM cell blade lookalike architecture,
> using full blown linux on core 0, using the other cores as worker
> threads.
> Possible target CPUs are Octeon II with 32 cores or more.
> 
> The main goal for this would be to reduce interrupt latency for worker
> cores, having them run possibly bare-bone with an IPC method between
> core 0 and worker cores. probably DMA and HW IRQs.
> 

As you may be aware, this is a common use case for current users of 
Octeon SOCs.

> Is there an existing system design in the kernel already that I can
> expand/use ? Perhaps expanding/porting the cell blade IPC method.
> What would you guys think would be the most efficient approach(and
> perhaps would be acceptable to the LK maintainers for merging at a
> later stage :) )  ?

Current Octeon applications, architected as you indicate, typically use 
the SOC's work queue hardware for IPC, but this is via custom drivers, 
not any existing kernel framework.

Since one of my main job functions is kernel development for the Octeon 
family, I would certainly be interested in any work done in this area.


David Daney

      parent reply	other threads:[~2009-05-19 16:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-19 11:58 Feasibility study: Linux on core 0, using other cores as worker cores. Octeon II linux kernel
2009-05-19 16:16 ` Maciej W. Rozycki
2009-05-19 16:43 ` David Daney [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=4A12E1AD.6000302@caviumnetworks.com \
    --to=ddaney@caviumnetworks.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linuxk3rnel@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.