bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mach ports use


From: Niels Möller
Subject: Re: Mach ports use
Date: 28 Oct 2002 22:53:27 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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.

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.

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.

Non-blocking is important, you don't want to have a bunch of threads
just in order to have more than one packet in the queue at a time.

When transmission of a packet is finished, an rpc is sent back to the
client, telling it that there is now one more slot available in the
queue for reuse.

In order to make this scheme safe, one would aither want to put the
control information in a separate area not shared with the client, or
lock the appropriate memory area while it is in the care of the sirver
and hardware.

Locking the memory area seems to be the solution that fits best with
your model of memory management. That implies, I guess, that either each
entry in the queue must be on it's own page. Or the client will do
some local buffering, giving a bunch of packets at a time to the
driver, when either (i) it has collected a full page of data, or (ii)
the driver's queue is getting empty.

To me, these issues seem a little hairy. Library functions to take
care of the details would be cool, in particular if this kind of
communication is useful in more contexts than just network card
programming.

Regards,
/Niels




reply via email to

[Prev in Thread] Current Thread [Next in Thread]