From owner-cvs-all Tue Jul 27 8:43:19 1999 Delivered-To: cvs-all@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 9C3991543C; Tue, 27 Jul 1999 08:43:11 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id JAA22174; Tue, 27 Jul 1999 09:42:38 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199907271542.JAA22174@caspian.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Mike Smith Cc: "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 "Tue, 27 Jul 1999 08:26:44 PDT." <199907271526.IAA03481@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Jul 1999 09:42:38 -0600 From: "Justin T. Gibbs" Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk >> 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? We control the sender, so the payload doesn't need to be unwrapped. >> 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? We can't. >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). We have access to the Tigon firmware and will add a special receive ring for packets to specific port addresses, etc. This is the reason why I would not expect FreeBSD to support this configuration directly. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message