linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspin.com>
To: "David S. Miller" <davem@redhat.com>
Cc: 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 17:20:41 -0700	[thread overview]
Message-ID: <52llv2vu06.fsf@topspin.com> (raw)
In-Reply-To: <20030713160200.571716cf.davem@redhat.com>

    David> I didn't say I agree with all of Moguls ideas, just his
    David> anti-TOE arguments.  For example, I also think RDMA sucks
    David> too yet he thinks it's a good iea.

Sure, he talks about some weaknesses of TOE, but his conclusion is
that the time has come for OS developers to start working on TCP
offload (for storage).

    David> You obviously don't understand my ideas if you think that
    David> it matters whether there is some relationship between the
    David> MTU and the system page size necessary for the scheme to
    David> work.

I was just quoting part of Mogul's paper that seemed to directly
contradict your original post.  I also said it would be great to see
NIC hardware with support for flow classification.

Look, I pretty much agree with you about TOE hardware.  Every chip
I've seen either requires a bunch of dedicated expensive memory
(including a giant CAM) or is just firmware running on a
low-performance embedded CPU.  But I also think Mogul is right: iSCSI
HBAs are going to force OS designers to deal with TCP offload.

My whole point was just that it doesn't make much sense to dismiss the
whole idea by saying "TOE is evil" and then cite as support a paper
that explains why TOEs now make sense and need to be supported.

 - Roland

  parent reply	other threads:[~2003-07-14  0:06 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
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 [this message]
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=52llv2vu06.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).