From: Jeff Garzik <jgarzik@pobox.com>
To: netdev@oss.sgi.com
Cc: leonid.grossman@s2io.com, Linux Kernel <linux-kernel@vger.kernel.org>
Subject: The ultimate TOE design
Date: Wed, 15 Sep 2004 15:33:47 -0400 [thread overview]
Message-ID: <4148991B.9050200@pobox.com> (raw)
(reply-to set to netdev)
Every now and then people ask on the lists about TOE, TCP assist, and
that sort of thing. Ignoring the issue of TCP hardware assist, I wanted
to describe what I feel is an optimal method to _fully offload_ the
Linux TCP stack.
Put simply, the "ultimate TOE card" would be a card with network ports,
a generic CPU (arm, mips, whatever.), some RAM, and some flash. This
card's "firmware" is the Linux kernel, configured to run as a _totally
indepenent network node_, with IP address(es) all its own.
Then, your host system OS will communicate with the Linux kernel running
on the card across the PCI bus, using IP packets (64K fixed MTU).
This effectively:
1) fragment processing, IPsec, and other services onto the card.
2) You can use huge card<->host MTUs, which makes sendfile(2) faster
with _zero_ kernel changes
3) You can let the PCI card do 100% of the checksum
processing/generation, and treat the network connection connection
across the PCI bus as CHECKSUM_UNNECESSARY.
2) With enough RAM and cpu cycles, you can even offload complex services
like Web services: the PCI card runs Apache, and fetches files across
the network (your PCI bus!) from the host system.
3) Does not require _any_ modification of Linux network stack.
Interfacing with the card merely requires a simple DMA interface to copy
IP (not ethernet) packets across the PCI bus, and that fits within the
existing Linux net driver API.
4) ensures that the TOE "firmware" [the Linux kernel] can be easily
updated in the event of new features or (more importantly) security
problems.
5) Linux is the most RFC-compliant net stack in the world. Why
re-create (or license) an inferior one?
6) Long-term maintenance of TOE firmware is a BIG problem with existing
full-TOE systems. Under this design, sysadmins would update and patch
their PCI card with security updates just like any other system on their
network. This is added work, yes, but it's a known quantity and a task
they are already doing for other systems.
7) The design is both portable [tons of embedded CPUs, with and without
MMUs, can run Linux] and scalable.
My dream is that some vendor will come along and implement such a
design, and sell it in enough volume that it's US$100 or less. There
are a few cards on the market already where implementing this design
_may_ be possible, but they are all fairly expensive. Just need enough
resources on the PCI to be able to Linux as a
router/firewall/iSCSI/web-proxy gadget.
And I'm not aware of anybody doing a direct IP-over-PCI thing, either.
But I'll keep on dreaming... ;-)
Jeff
next reply other threads:[~2004-09-15 19:33 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-15 19:33 Jeff Garzik [this message]
2004-09-15 20:04 ` The ultimate TOE design 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
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=4148991B.9050200@pobox.com \
--to=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).