Date: Tue, 27 Jul 1999 11:05:03 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Mike Smith <mike@smith.net.au> Cc: "Justin T. Gibbs" <gibbs@caspian.plutotech.com>, "Justin T. Gibbs" <gibbs@plutotech.com>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/release/sysinstall tcpip.c Message-ID: <Pine.BSF.3.95.990727105645.29565B-100000@current1.whistle.com> In-Reply-To: <199907271526.IAA03481@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Jul 1999, Mike Smith wrote: > > >Hmm. Would you be using a second mbuf with external storage pointing > > >to the other device's memory to account for the payload? > > > > Yes. > > Ok. So making ether_input DTRT with mbuf chains would work too. > > > >Is this a short-circuit routing technique, or just immediate delivery > > >of payload data? Who unpacks the data that's going to the target > > >peripheral? > > > > The target area is a RAM buffer/parity generating device that for all > > intents and purposes looks just like CPU memory to any device on the PCI > > bus. We want to dump the data directly to this "external" ram, compute > > parity, and then ship the data either to our A/V board or out to > > disk. Since we need to sustain an aggregate bandwidth of 50-100MB/s > > (depends on configuration), doing an extra copy is not a pleasant > > option. > > Understood. I presume that you'll be handling the unwrappping of the > payload in this second shipping-out phase? > > > I don't expect FreeBSD to support this configuration out > > of the box (we need the target to be a specific physical address, not > > just any old page shoved into our user address space), but I do expect > > us to support zero-copy receive for more standard applications so long > > as they allocate receive space in a sane fashion. > > I have to admit that I cannot see how you can hope to do zero-copy on > receive. How are you going to know in advance what the next datagram > is going to be? You need to know that in order to set up the scatter/ > gather to get the payload into the recipient's buffer, but you don't > know which potential recipient the next datagram is for, nor whether > the next datagram is even going to be for them (as opposed to, say, an > ICMP or ARP message). This Depends on your definition of 'zero copy'. At TRW we used local DMA into the buffer on the ethernet card (4MB/card) and then the disk driver DMA'd if from that memory, to the disk. so it was "single DMA" (across the bus) but zero copy from the point of view of the CPU. Our image servers were capable in 1993 of saturating 10 ethernets (not much now) with about 15% CPU usage. I'd love to do some of this stuff again.. it was really fun.. BTW this is where FreeBSD got it's (old) SCSI system from, and why there was an #ifdef TFS in it that used Physical addresses fron a UIO/iovec, rather than virtual address. it's also why thre was a bunch of "#ifdef BIG_PACKET" stuff in the de driver, to support jumbo frames. The next generation of image servers were going to be made with special PCI cards that had the ethernet (100 baseT) interfaces on a card on the SCSI bus so that data was DMA'd there rather than to the main memory. That project was never completed however. > > -- > \\ 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?Pine.BSF.3.95.990727105645.29565B-100000>