linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Valdis.Kletnieks@vt.edu
To: "David S. Miller" <davem@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-net@vger.kernel.org,
	netdev@oss.sgi.com
Subject: Re: TCP IP Offloading Interface
Date: Sun, 13 Jul 2003 20:46:38 -0400	[thread overview]
Message-ID: <200307140046.h6E0kcMQ021180@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Sun, 13 Jul 2003 16:53:23 PDT." <20030713165323.3fc2601f.davem@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

On Sun, 13 Jul 2003 16:53:23 PDT, "David S. Miller" said:

> I really don't see why receive is so much of a big deal
> compared to send, and we do a send side version of this
> stuff already with zero problems.

Well.... there's optimizations you can do on the send side..

> The NFS code is already basically ready to handle a fragmented packet
> (headers + pages), and could stick the page part into the page cache
> easily on receive.

For example, in this case, you know a priori what the IP header will look
like, so you can use tricks like scatter-gather to send the header from one
place and a page-aligned data buffer from another, or start the packet at
(page boundary - IP_hrd_len), or tricks of that sort.  In 20 years, I've seen
a lot of vendors do a lot of ugly things to speed up their IP stack, often
based on the fact that they knew a lot about the packet before they started
assembling it.

It's hard to do tricks like that when you don't know (for instance) how
many IP option fields the packet has until you've already started sucking
the packet off the wire - at which point either the NIC itself has to be clever
(Hmm, there's that IP offload again) or you have literally about 30 CPU cycles
to do interrrupt latency *and* decide what to do....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

  parent reply	other threads:[~2003-07-14  0:32 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 [this message]
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=200307140046.h6E0kcMQ021180@turing-police.cc.vt.edu \
    --to=valdis.kletnieks@vt.edu \
    --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).