From: Roland Dreier <roland@topspin.com>
To: "David S. Miller" <davem@redhat.com>
Cc: "Alan Shih" <alan@storlinksemi.com>,
linux-kernel@vger.kernel.org, linux-net@vger.kernel.org,
netdev@oss.sgi.com
Subject: Re: TCP IP Offloading Interface
Date: 13 Jul 2003 09:22:32 -0700 [thread overview]
Message-ID: <52u19qwg53.fsf@topspin.com> (raw)
In-Reply-To: <20030713004818.4f1895be.davem@redhat.com>
David> TOE is evil, read this:
David> http://www.usenix.org/events/hotos03/tech/full_papers/mogul/mogul.pdf
David> TOE is exactly suboptimal for the very things performance
David> matters, high connection rates.
David> Your return is also absolutely questionable. Servers
David> "serve" data and we offload all of the send side TCP
David> processing that can reasonably be done (segmentation,
David> checksumming).
David> I've never seen an impartial benchmark showing that TCP
David> send side performance goes up as a result of using TOE
David> vs. the usual segmentation + checksum offloading offered
David> today.
David> On receive side, clever RX buffer flipping tricks are the
David> way to go and require no protocol changes and nothing gross
David> like TOE or weird buffer ownership protocols like RDMA
David> requires.
David> I've made postings showing how such a scheme can work using
David> a limited flow cache on the networking card. I don't have
David> a reference handy, but I suppose someone else does.
Your ideas are certainly very interesting, and I would be happy to see
hardware that supports flow identification. But the Usenix paper
you're citing completely disagrees with you! For example, Mogul writes:
"Nevertheless, copy-avoidance designs have not been widely adopted,
due to significant limitations. For example, when network maximum
segment size (MSS) values are smaller than VM page sizes, which is
often the case, page-remapping techniques are insufficient (and
page-remapping often imposes overheads of its own.)"
In fact, his conclusion is:
"However, as hardware trends change the feasibility and economics of
network-based storage connections, RDMA will become a significant
and appropriate justification for TOEs."
- Roland
next prev parent reply other threads:[~2003-07-13 16:08 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-13 7:33 TCP IP Offloading Interface Alan Shih
2003-07-13 7:48 ` David S. Miller
2003-07-13 16:22 ` Roland Dreier [this message]
2003-07-13 16:31 ` Alan Cox
2003-07-13 16:49 ` Jeff Garzik
2003-07-13 16:58 ` Jeff Garzik
2003-07-13 23:02 ` David S. Miller
2003-07-13 23:35 ` Larry McVoy
2003-07-13 23:40 ` David S. Miller
2003-07-13 23:54 ` Larry McVoy
2003-07-13 23:53 ` David S. Miller
2003-07-14 0:22 ` Larry McVoy
2003-07-14 0:24 ` David S. Miller
2003-07-14 0:48 ` Larry McVoy
2003-07-14 0:46 ` Valdis.Kletnieks
2003-07-14 0:42 ` David S. Miller
2003-07-16 2:46 ` Matt Porter
2003-07-14 0:20 ` Roland Dreier
2003-07-14 0:28 ` David S. Miller
2003-07-16 2:37 ` Matt Porter
2003-07-13 14:51 ` Jeff Garzik
[not found] <E3738FB497C72449B0A81AEABE6E713C027A43@STXCHG1.simpletech.com>
2003-07-15 5:51 ` David S. Miller
2003-07-16 5:02 ` jamal
2003-07-16 1:51 ` Roland Dreier
2003-07-15 16:28 David griego
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=52u19qwg53.fsf@topspin.com \
--to=roland@topspin.com \
--cc=alan@storlinksemi.com \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@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).