netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@redhat.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: David Stevens <dlstevens@us.ibm.com>, Netdev <netdev@oss.sgi.com>,
	leonid.grossman@s2io.com,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: The ultimate TOE design
Date: Wed, 15 Sep 2004 16:54:30 -0400	[thread overview]
Message-ID: <4148AC06.60400@redhat.com> (raw)
In-Reply-To: <4148A51F.7030909@pobox.com>

Jeff Garzik wrote:
> David Stevens wrote:
> 
>> I've never understood why people are so interested in off-loading
>> networking. Isn't that just a multi-processor system where you can't
>> use any of the network processor cycles for anything else? And, of
>> course, to be cheap, the network processor will be slower, and much
>> harder to debug and update software.
> 
> 
> Well I do agree there is a strong don't-bother-with-TOE argument: 
> Moore's law, the CPUs (manufactured in vast quantities) will usually
> 
> 
> However, there are companies are Just Gotta Do TOE...  and I am not 
> inclined to assist in any effort that compromises Linux's RFC compliancy 
> or security.  Current TOE efforts seem to be of the "shove your data 
> through this black box" variety, which is rather disheartening.
> 
> Even non-TOE NICs these days have ever-more-complex firmwares.  tg3 is a 
> MIPS-based engine for example.
> 
> 
>> If the PCI bus is too slow, or MTU's too small, wouldn't
>> it be better to fix those directly and use a fast host processor that can
>> also do other things when not needed for networking? And why have
>> memory on a NIC that can't be used by other things?
> 
> 
> PCI bus tends to be slower than DRAM<->CPU speed, and MTUs across the 
> Internet will be small as long as ethernet enjoys continued success.
> 
>     Jeff

There is also something to be said for the embedded market here. 
offload chips are fairly usefull when building switches and routers. 
Dave M. in a thread just a few weeks ago provided some metrics for how 
much bandwidth a PCI-x bus and a some-odd-gigahertz processor could 
handle.  It worked that a pc with the right componenets could 
theoretically handle about 4 gigahertz nics running traffic full duplex 
at line rate.  Thats great, but it doesn't come close to what you need 
for a 24 port gigabit L3 switch, nor does it approach the correct price 
point.  Most of these designs use a less expensive processor running at 
a slower speed, and an offload chip (that incorporates tx/rx logic and a 
switching fabric) to preform most of the routing and switching.  For 
cost concious network equipment manufacturers, they are really the way 
to go.  Unfortunately, many of them don't actaully run as a 
co-processor, and so don't enable Jeff's idea very well (yet :))

Neil

-- 
/***************************************************
  *Neil Horman
  *Software Engineer
  *Red Hat, Inc.
  *nhorman@redhat.com
  *gpg keyid: 1024D / 0x92A74FA1
  *http://pgp.mit.edu
  ***************************************************/

  reply	other threads:[~2004-09-15 20:54 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-15 19:33 The ultimate TOE design Jeff Garzik
2004-09-15 20:04 ` Paul Jakma
2004-09-15 19:14   ` Alan Cox
2004-09-15 20:41     ` Jeff Garzik
2004-09-15 21:01       ` David S. Miller
2004-09-15 21:08         ` Jeff Garzik
2004-09-15 21:13           ` David S. Miller
2004-09-15 21:23             ` Jeff Garzik
2004-09-15 21:29               ` David S. Miller
2004-09-15 22:26                 ` Jeff Garzik
2004-09-15 23:29                 ` Leonid Grossman
2004-09-24 13:07                   ` Lennert Buytenhek
2004-09-24 13:21                     ` Leonid Grossman
2004-09-24 18:09                       ` Lennert Buytenhek
2004-09-24 19:39                         ` Joel Jaeggli
2004-09-16  0:57               ` jamal
2004-09-16  5:25                 ` Leonid Grossman
2004-09-16  9:29               ` Lincoln Dale
2004-09-16 12:19                 ` Alan Cox
2004-09-16 13:33                   ` Andi Kleen
2004-09-16 12:57                     ` Alan Cox
2004-09-16 22:37                       ` Lincoln Dale
2004-09-17 13:38                         ` Jörn Engel
2004-09-15 22:31             ` Jeff Garzik
2004-09-15 21:15         ` Michael Richardson
2004-09-15 20:53     ` David S. Miller
2004-09-16  1:05       ` Andrea Arcangeli
2004-09-15 21:10     ` David Lang
2004-09-15 23:05     ` Paul Jakma
2004-09-15 20:26   ` Neil Horman
2004-09-15 21:03     ` Wes Felter
2004-09-15 21:15       ` Jeff Garzik
2004-09-15 21:35         ` Wes Felter
2004-09-15 21:42           ` Jeff Garzik
2004-09-15 21:25       ` Imran Badr
2004-09-16 11:37       ` Neil Horman
2004-09-16  5:51     ` Matt Porter
2004-09-15 21:36   ` Deepak Saxena
2004-09-15 23:03     ` Paul Jakma
2004-09-24 13:11     ` Lennert Buytenhek
2004-09-15 21:59   ` Tony Lee
2004-09-15 20:11 ` David Stevens
2004-09-15 20:16   ` David Schwartz
2004-09-15 20:25   ` Jeff Garzik
2004-09-15 20:54     ` Neil Horman [this message]
2004-09-15 20:31   ` Bill Rugolsky Jr.
2004-09-15 21:41   ` Joel Jaeggli
2004-09-16  6:33   ` Valdis.Kletnieks
2004-09-17  6:46   ` Eric Mudama
2004-09-17 14:15     ` Alan Cox
2004-09-17 20:27     ` Valdis.Kletnieks
2004-09-17 20:36       ` David Lang
2004-09-17 23:20         ` Tony Lee
2004-09-17 23:36           ` Leonid Grossman
2004-09-22 23:25       ` Eric Mudama
2004-09-15 21:36 ` John Heffner
2004-09-15 21:46   ` David S. Miller
2004-09-16  6:20     ` Andi Kleen
2004-09-16 13:10       ` Leonid Grossman
2004-09-16 16:18         ` Nivedita Singhvi
2004-09-16 20:34           ` Leonid Grossman
2004-09-22 20:18             ` Nivedita Singhvi
2004-09-23  4:46               ` Leonid Grossman
2004-09-15 23:16   ` James Morris
2004-09-15 23:37     ` Leonid Grossman
2004-09-15 23:52     ` John Heffner
2004-09-16  1:43       ` James Morris
2004-09-16  9:03 ` Lars Marowsky-Bree
     [not found] <1095328673.1063.130.camel@jzny.localdomain>
2004-09-16 14:57 ` Leonid Grossman

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=4148AC06.60400@redhat.com \
    --to=nhorman@redhat.com \
    --cc=dlstevens@us.ibm.com \
    --cc=jgarzik@pobox.com \
    --cc=leonid.grossman@s2io.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.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).