Date: Tue, 27 Jul 1999 01:07:17 -0700 From: Mike Smith <mike@smith.net.au> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Mike Smith <mike@smith.net.au>, "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: <199907270807.BAA01251@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 23 Jul 1999 10:53:31 PDT." <199907231753.KAA26727@apollo.backplane.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. Er, Matt. Sendfile is, like, an output function. ether_input is, like, input and stuff. > 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. Yecch. You appear to be channeling Terry. For output, extra mbufs are chained onto the sendfile-allocated buffer (actually an mbuf with an sf_buf attached as external storage). > You can blame the 6-byte MAC header for most of the headaches. Actually, I blame the way that layered protocol information is prefixed rather than postfixed in the datagram's wire format. It doesn't strike me as being at all well designed from a performance perspective (although mbuf chaining helps a lot). It would be possible to reduce both copying and checksum overheads by preallocating trailing space in the buffer based on the down-stack path (or even just a worst-case assessment of potential buffer growth), and adding an incremental checksum field. But this would make you totally incompatible with everything else, so let's just forget that line of thought. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.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?199907270807.BAA01251>