netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: girouard@us.ibm.com
Cc: garzik@pobox.com, shemminger@osdl.org, Valdis.Kletnieks@vt.edu,
	stekloff@us.ibm.com, lkessler@us.ibm.com,
	linux-kernel@vger.kernel.org, netdev@oss.sgi.com, niv@us.ibm.com
Subject: Re: patch for common networking error messages
Date: Tue, 17 Jun 2003 13:42:06 -0700 (PDT)	[thread overview]
Message-ID: <20030617.134206.133917056.davem@redhat.com> (raw)
In-Reply-To: <OF296D6F92.1C7252A9-ON85256D48.00713BCF@us.ibm.com>

   From: Janice Girouard <girouard@us.ibm.com>
   Date: Tue, 17 Jun 2003 15:40:48 -0500
   
   From:  David S. Miller" <davem@redhat.com>
         Date: 06/17/2003 03:27 PM
   
         On RX, clever RX buffer management is what we need.
   
   What RX buffer management are you proposing?  I'm having a hard time
   understanding how  you'll get rid of the copy without support from the
   card.
   
Sigh... someone write store email down somewhere for the next time
someone asks about this.

The "one true way (tm)" works like this:

1) Chip has a "flow cache", LRU based, managed like routing caches
    in many production router implementations.  Difference is
    that it merely does flow watching.

    Flow entries are keyed on saddr/daddr/sport/dport.  Flow misses
    kill the oldest entry, and replace it with the new one.

    Entries are only created in response to full sized data
    packets.

2) The receive buffering is segmented into small (256 byte) and
    PAGE sized buffers.  IP/TCP/whatever headers (determined using
    a simply programmable header parser logic, so you can do things
    like RPC etc. headers for NFS) are put into the "small" buffers,
    data portions for matching flows get accumulated into the PAGE
    sized buffers.

    It is implied that the card's flow cache keeps track of the
    pointers into page it is currently trying to fill for that
    flow.

So the first time you see a flow, you add a entry and grab a page
buffer and stick the data part into the page buffer and the
TCP/IP/etc. headers into a "small" buffer.  You defer a configurable
amount of time waiting for more TCP data packets (a packet train)
to accumulate more into the PAGE buffer for that flow.

Such receive buffers are presented to the stack as a linked list
of packets, with some indicator that together their data parts are
filling a page.

Things like "sys_receivefile()" and NFS flip these things into the
filesystem page cache.

I'm surprised this isn't evident to more people...

  reply	other threads:[~2003-06-17 20:42 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-17 20:40 patch for common networking error messages Janice Girouard
2003-06-17 20:42 ` David S. Miller [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-06-17 20:57 Janice Girouard
2003-06-17 21:14 ` David S. Miller
2003-06-17  2:12 Janice Girouard
2003-06-17  4:34 ` Valdis.Kletnieks
2003-06-17 16:08   ` Stephen Hemminger
2003-06-17 16:09     ` David S. Miller
2003-06-17 18:46       ` Jeff Garzik
2003-06-17 19:06         ` Janice M Girouard
2003-06-17 19:23           ` Jeff Garzik
2003-06-17 19:46             ` Janice M Girouard
2003-06-17 19:50               ` David S. Miller
2003-06-17 20:24                 ` Janice M Girouard
2003-06-17 20:27                   ` David S. Miller
2003-06-17  0:44 Janice Girouard
2003-06-17  1:19 ` David S. Miller
2003-06-17 14:34   ` Mr. James W. Laferriere
2003-06-16 22:50 Janice Girouard
2003-06-16 22:55 ` David S. Miller
2003-06-21 12:36   ` Alan Cox
2003-06-21 14:27     ` Jamal Hadi
2003-06-23  0:46     ` David S. Miller
2003-06-23 11:54       ` Alan Cox
2003-06-16 22:29 Janice Girouard
2003-06-16 22:27 ` David S. Miller
2003-06-16 22:45   ` Nivedita Singhvi
2003-06-16 22:52     ` David S. Miller
2003-06-17  0:07       ` Nivedita Singhvi
2003-06-16 20:30 Janice M Girouard
2003-06-16 20:38 ` David S. Miller
2003-06-16 20:53   ` Andi Kleen
2003-06-16 20:51     ` David S. Miller
2003-06-16 22:27       ` Andrew Morton
2003-06-17  7:09         ` Andi Kleen
2003-06-17  7:20           ` Andrew Morton
2003-06-16 20:59   ` Janice M Girouard
2003-06-16 22:48     ` Jeff Garzik
2003-06-16 22:52       ` Jeff Garzik
2003-06-16 22:13 ` Nivedita Singhvi
2003-06-16 22:13   ` David S. Miller
2003-06-16 22:50     ` Nivedita Singhvi
2003-06-16 22:57       ` David S. Miller
2003-06-16 23:02   ` Donald Becker

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=20030617.134206.133917056.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=garzik@pobox.com \
    --cc=girouard@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkessler@us.ibm.com \
    --cc=netdev@oss.sgi.com \
    --cc=niv@us.ibm.com \
    --cc=shemminger@osdl.org \
    --cc=stekloff@us.ibm.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).