netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: dmitry_yus@yahoo.com, open-iscsi@googlegroups.com,
	mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu,
	James.Bottomley@HansenPartnership.com,
	ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com
Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics)
Date: Mon, 4 Apr 2005 10:31:25 -0600	[thread overview]
Message-ID: <20050404163125.GA6809@colo.lackof.org> (raw)
In-Reply-To: <20050404001000.5fa8f206.davem@davemloft.net>

On Mon, Apr 04, 2005 at 12:10:00AM -0700, David S. Miller wrote:
> On Mon, 4 Apr 2005 00:34:56 -0600
> Grant Grundler <grundler@parisc-linux.org> wrote:
> 
> > Yes and No. PCI-X isn't fast enough but the data only crosses
> > the PCI-X bus once.  Think about the data flow:
> > 	1) DMA to RAM
> > 	2) load into CPU cache
> > 	3) store back into RAM
> > 
> > We are down to 40% left...graphics folks won't like you.
> 
> But you're missing the point, which is that the memory system
> always catches up to the networking technology.

No. Bus bandwidth catches up to "a" networking technology - not
the "current" technology.
Networking and graphics are usually starving for bus bandwidth.

> We'll have that %60 back before you know it when we have
> PCI-Z and DDR8 or whatever even in $500.00USD desktop machines.

Yes, I agree. That's certainly how it went for 100bt and gige.
Even laptops come with gige now. But we aren't in that part
"of the curve" for IB or 10GigE *yet*.

> And those systems will be present by the time we put together
> this complicated infrastructure for RDMA.

And that will be fine for "general use".

> RDMA is like cache coloring page allocators, it's for yesterday's
> technology that we won't be using tomorrow. :-)
> 
> Those steps #2 and #3 in your data flow are powerful, it is what
> gives us flexibility.

Agreed - some very cool things have been done with it.
And for general use, it'll perf sufficiently well over gige.
In the future, I agree IB or 10gigE will too.

> And in a general purpose OS that is important.

I think most of the people interested in IB and 10GigE aren't looking
for "general use". They have a particular application in mind
and they want to maximize performance for dollar spent.
Things like "science appliance", "router", "data warehouse" come to mind.

"General Use" will be a reality only when the dollar cost comes down
so those new technologies can compete with gige.

thanks,
grant

  parent reply	other threads:[~2005-04-04 16:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-02 19:07 [Ksummit-2005-discuss] Summary of 2005 Kernel Summit ProposedTopics Asgeir Eiriksson
2005-04-02 19:14 ` Ming Zhang
2005-04-04  0:56 ` Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Dmitry Yusupov
2005-04-04  6:34   ` Grant Grundler
2005-04-04  7:10     ` David S. Miller
2005-04-04 12:58       ` Ming Zhang
2005-04-04 16:31       ` Grant Grundler [this message]
2005-04-04 12:56     ` Ming Zhang
2005-04-04 16:54     ` Dmitry Yusupov
2005-04-04 19:11       ` Grant Grundler
  -- strict thread matches above, loose matches on Subject: below --
2005-04-05 22:19 jaganav
2005-04-02  7:29 jaganav
2005-04-02 18:27 ` Matthew Wilcox
2005-04-03  1:26 ` Grant Grundler
2005-04-05 15:04 ` Rik van Riel
2005-04-01  2:13 jaganav
2005-04-01 23:43 ` Stephen Hemminger
2005-04-02  1:37   ` jaganav
2005-04-02  5:27     ` Greg KH
2005-04-02  6:02       ` Greg KH
2005-04-02 15:01         ` Andrea Arcangeli
2005-04-04 16:50     ` Stephen Hemminger
     [not found] <4241D106.8050302@cs.wisc.edu>
     [not found] ` <20050324101622S.fujita.tomonori@lab.ntt.co.jp>
     [not found]   ` <1111628393.1548.307.camel@beastie>
     [not found]     ` <20050324113312W.fujita.tomonori@lab.ntt.co.jp>
     [not found]       ` <1111633846.1548.318.camel@beastie>
     [not found]         ` <20050324215922.GT14202@opteron.random>
     [not found]           ` <424346FE.20704@cs.wisc.edu>
     [not found]             ` <20050324233921.GZ14202@opteron.random>
     [not found]               ` <20050325034341.GV32638@waste.org>
     [not found]                 ` <20050327035149.GD4053@g5.random>
2005-03-27  5:48                   ` [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics Matt Mackall
2005-03-27  6:33                     ` Dmitry Yusupov
2005-03-27  6:46                       ` David S. Miller
2005-03-28 19:45                         ` Roland Dreier
     [not found]                           ` <1112042936.5088.22.camel@beastie>
2005-03-28 22:32                             ` Benjamin LaHaise
2005-03-29  3:19                               ` Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Roland Dreier
2005-03-30 16:00                                 ` Benjamin LaHaise
2005-03-29  3:14                             ` Roland Dreier

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=20050404163125.GA6809@colo.lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=andrea@suse.de \
    --cc=davem@davemloft.net \
    --cc=dmitry_yus@yahoo.com \
    --cc=ksummit-2005-discuss@thunk.org \
    --cc=michaelc@cs.wisc.edu \
    --cc=mpm@selenic.com \
    --cc=netdev@oss.sgi.com \
    --cc=open-iscsi@googlegroups.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 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).