Re: Mach ports use

[Peter 'p2' De Schrijver]

On Mon, Oct 28, 2002 at 10:53:27PM +0100, Niels Möller wrote:
> neal@cs.uml.edu (Neal H. Walfield) writes:
> 
> > The client would make a container containing the pages and give the
> > server access to the container.  Then the server would map the pages
> > in the container, build a packet and send it down the network.  Upon
> > return, the client could reject the server's access to the container
> > or fill it with another pay load and continue.
> 
> I'm out on somewhat thin ice here, but I've heard the following
> explanation of network card programming:
> 
> The network card and the driver shares two circular buffers containing
> data and some control information. The network card uses dma to read
> data from the send queue, and to write to the receive queue.
> 

Typically you have two lists of pointers. 1 list points to buffers containing 
data to be transmitted. The other list points to buffers available for 
incoming frames. Apart from the pointers to the buffers, the list
entries also contain status information. Some chips can read/write 1
frame from/to multiple buffers. So you can put the headers in another
buffer than the user data (think of it as hw support for a chain of
mbufs).  That's for the more intelligent cards. Dumber chips (eg, the
rtl8139) just have a ring buffer for reception (which contains the
incoming frames, not pointers) and some registers containing pointers to
memory blocks to be transmitted. In this case you're almost forced to
copy data on reception. Some older 10Mbps only cards don't support DMA
at all. You have to use PIO to get data in and out of the packet buffer.
This is typically the case for all 8390 based cards (NE2k and the
likes).

> One generally wants a circular queue with more than one element, so
> that the network card immediately can go on getting the next packet to
> transmit, without having to wait for the operating system to process
> interrupts, and then tell it to go on.
> 

Indeed you typically need a few buffers ready for incoming frames and
you obviously want to fill the transmit list so the card can transmit
frames as fast as possible.

> My (possibly naive) view on how to do this on l4 would be to share
> some memory with the driver, preferably memory of some type that can
> be used directly for dma. The i/o client would write data at the tail
> of the circular queue (or wait until space becomes available), and
> then make an rpc to the driver. The driver would fill out the
> (hardware-dependent) control information, and make sure the packet is
> scheduled for transmission by the networking card. While the packet is
> being queued and transmitted, the client will go on, trying to enqueue
> more packets, or doing other work.
> 

For transmission : I would just have the client transfer the ownership
of the page containing the data to the driver. The driver can then add
a pointer to this data to the transmit queue. When the frame is
transmitted, the page can be released. 

Cheers,

p2.