Date: Fri, 23 Jul 1999 10:53:31 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mike Smith <mike@smith.net.au> Cc: "Justin T. Gibbs" <gibbs@caspian.plutotech.com>, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/release/sysinstall tcpip.c Message-ID: <199907231753.KAA26727@apollo.backplane.com> References: <199907231736.KAA03557@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> >So is there any reasonable expectation that we will have to deal with
:> >hardware that won't result in the driver placing the ethernet header
:> >immediately before the payload in the mbuf? This would result in us
:> >having to copy it around, which would be slightly yucky.
:>
:> In zero copy applications, the header and the payload are usually placed
:> in separate areas.
:
:Can you elaborate on this a little? We don't support the two being in
:a separate allocation unit at the moment, yet I understood the 'fast
:forwarding' code was essentially a zero-copy operation.
:--
:\\ The mind's the standard \\ Mike Smith
I believe sendfile() is a good example of this. The pages from the
file being sent are mapped into mbuf's directly and the headers are
dealt with separately.
Not all ether drivers support this. Actually, only a very few do I
think. Some can't align DMA on a 16-bit boundry, and some can't do
scatter-gather for packets. scatter-gather is necessary to avoid the
worst of the copying overhead. Devices which require 32 bit DMA alignment
can hopefully do scatter-gather so only the packet header needs to be
copied.
You can blame the 6-byte MAC header for most of the headaches.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907231753.KAA26727>