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
***************************************************/
next prev parent 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).