Date: Tue, 27 Jul 1999 09:20:38 -0600 From: "Justin T. Gibbs" <gibbs@caspian.plutotech.com> To: Mike Smith <mike@smith.net.au> Cc: "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: <199907271520.JAA22128@caspian.plutotech.com> In-Reply-To: Your message of "Tue, 27 Jul 1999 01:10:24 PDT." <199907270810.BAA01282@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Hmm. Would you be using a second mbuf with external storage pointing >to the other device's memory to account for the payload? Yes. >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. 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. -- Justin 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?199907271520.JAA22128>