Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Jul 1999 08:26:44 -0700
From:      Mike Smith <mike@smith.net.au>
To:        "Justin T. Gibbs" <gibbs@caspian.plutotech.com>
Cc:        Mike Smith <mike@smith.net.au>, "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:  <199907271526.IAA03481@dingo.cdrom.com>
In-Reply-To: Your message of "Tue, 27 Jul 1999 09:20:38 MDT." <199907271520.JAA22128@caspian.plutotech.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.

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).

-- 
\\  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?199907271526.IAA03481>