From: Michael Peddemors <michael@linuxmagic.com>
To: "Benjamin C.R. LaHaise" <blah@kvack.org>,
"David S. Miller" <davem@redhat.com>
Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [UPDATE] zerocopy.. While working on ip.h stuff
Date: Mon, 26 Feb 2001 19:41:54 -0800 [thread overview]
Message-ID: <0102261941540L.02007@mistress> (raw)
In-Reply-To: <Pine.LNX.3.96.1010226190859.12521B-100000@kanga.kvack.org>
In-Reply-To: <Pine.LNX.3.96.1010226190859.12521B-100000@kanga.kvack.org>
On Mon, 26 Feb 2001, Benjamin C.R. LaHaise wrote:
> On Mon, 26 Feb 2001, David S. Miller wrote:
> > At gigapacket rates, it becomes an issue. This guy is talking about
> > tinkering with new IP _options_, not just the header. So even if the
> > IP header itself fits totally in a cache line, the options afterwardsd
> > likely will not and thus require another cache miss.
Yes, I expect to use the whole of the allowed size :)
So instead of the more common IP Header length of 20 bytes, I will be using
25-60 bytes for a header, (But so does source routing) and the router RFC
says that we should handle it...
Now, of course, you have raised the question of whether that would be handled
effeciently with the current kernel code..
> Hmmm, one way around this is to have the packet queue store things in
> in a linear array of pointers to data areas, then process things in
> bursts, ie:
>
> - find packet data areas for queued packets
> - walk list doing prefetches of ip header and options
> - then actually do the packet processing (save output for later)
>
> That will require a number of new hooks for pipelining operations, though.
> Just a thought.
>
> -ben
--
"Catch the magic of Linux...."
--------------------------------------------------------
Michael Peddemors - Senior Consultant
Unix Administration - WebSite Hosting
Network Services - Programming
Wizard Internet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604) 589-0037 Beautiful British Columbia, Canada
--------------------------------------------------------
next prev parent reply other threads:[~2001-02-27 2:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-23 6:59 [UPDATE] zerocopy BETA 3 David S. Miller
2001-02-23 10:42 ` Jan Rekorajski
2001-02-25 3:38 ` Chris Wedgwood
2001-02-25 3:54 ` Jan Rekorajski
2001-02-26 23:46 ` [UPDATE] zerocopy.. While working on ip.h stuff Michael Peddemors
2001-02-26 23:23 ` Andi Kleen
2001-02-26 23:25 ` David S. Miller
2001-02-26 23:47 ` Benjamin C.R. LaHaise
2001-02-27 0:05 ` David S. Miller
2001-02-27 0:11 ` Benjamin C.R. LaHaise
2001-02-27 3:41 ` Michael Peddemors [this message]
2001-02-27 3:24 ` Michael Peddemors
2001-02-26 5:28 ` [UPDATE] zerocopy BETA 3 David S. Miller
[not found] <2137.983232656@ISI.EDU>
2001-02-27 1:53 ` [UPDATE] zerocopy.. While working on ip.h stuff Michael Peddemors
2001-02-27 2:31 ` Craig Milo Rogers
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=0102261941540L.02007@mistress \
--to=michael@linuxmagic.com \
--cc=blah@kvack.org \
--cc=davem@redhat.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