From owner-cvs-all Tue Jul 27 1:14:41 1999 Delivered-To: cvs-all@freebsd.org Received: from dingo.cdrom.com (castles554.castles.com [208.214.165.118]) by hub.freebsd.org (Postfix) with ESMTP id B20F2150A3; Tue, 27 Jul 1999 01:14:31 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id BAA01251; Tue, 27 Jul 1999 01:07:18 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907270807.BAA01251@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon Cc: Mike Smith , "Justin T. Gibbs" , cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/release/sysinstall tcpip.c In-reply-to: Your message of "Fri, 23 Jul 1999 10:53:31 PDT." <199907231753.KAA26727@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Jul 1999 01:07:17 -0700 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > :> >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