Subject: Re: Writing to disk from the network stack (bottom half of the kernel)
To: Bill Studenmund <email@example.com>
From: Paul Sommerhein <firstname.lastname@example.org>
Date: 02/05/2003 21:12:05
On Tue, Feb 04, 2003 at 09:38:25AM -0800, Bill Studenmund wrote:
> On Tue, 4 Feb 2003, Paul Sommerhein wrote:
> > Ok, this might not be feasible, but what I want to do is to write
> > a 64kB chunk of data to the end of a disk file from within the
> > network stack in the bottom half of the kernel (incoming data
> > path, no process context).
> What do you want to do? i.e. what's the bigger-picture goal?
Briefly. The goal is to construct an efficient upload protocol,
typically for a proxy server receiving large files (e.g. video).
I will try to make two versions. The first will be based on UDP
with a real time protocol sitting on top which is responsible for
controlling the incoming stream and retransmitting lost packets.
The second version will be based on TCP.
To reduce overhead several factors will be addressed. The most
important will be to reduce the number of disk accesses. This is
the reason I collect data into a 64kB contiguous memory chunk
before sending to disk (64kB is chosen based on the assumption
that the maximum disk request is 64kB). Another place I will save
cycles is to skip the copying up to and down from user space. I
also hope to save cycles by combining copying of data to the 64kB
buffer with the checksum operation for incoming data for TCP/UDP.
Besides all of this, I will save a number of context switches
compared to the alternative of waking up a process for every
> Note, with the addition of UBC, we no longer use the buffer
> cache for file data.
Ok, I wasn't aware of that. I work from the NetBSD-1.5.2 source.
Is the interface to the file system code using UBC a lot
different? I.e., will it be a lot of work to rewrite code
to work with the new UBC based file system code?
> Why not just create a kernel thread that reads the socket and
> writes the file?