Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[Ingo Molnar]

On Tue, 9 Jan 2001, Benjamin C.R. LaHaise wrote:

> Do the math again: for transmitting a single page in a kiobuf only 64
> bytes needs to be initialized.  If map_array is moved to the end of
> the structure, that's all contiguous data and is a single cacheline.

but you are comparing apples to oranges: an iobuf to a fragment-array. A
fragment-array is equivalent to an array of iobufs. In typical (eg. HTTP)
output we have mixed sendfile() and sendmsg() based output, so we have an
array of (page, offset, size) memory-areas, not a (initial_offset, page[])
array like kiobufs. The closest thing would be an array of kiobufs (where
each kiobuf would use a single page only).

this is why i ment that *right now* kiobufs are not suited for networking,
at least the way we do it. Maybe if kiobufs had the same kind of internal
structure as sk_frag (ie. array of (page,offset,size) triples, not array
of pages), that would work out better.

> What you're completely ignoring is that sendpages is lacking a huge
> amount of functionality that is *needed*. I can't implement clean
> async io on top of sendpages -- it'll require keeping 1 task around
> per outstanding io, which is exactly the bottleneck we're trying to
> work around.

Please take a look at next release of TUX. Probably the last missing piece
was that i added O_NONBLOCK to generic_file_read() && sendfile(), so not
fully cached requests can be offloaded to IO threads.

Otherwise the current lowlevel filesystem infrastructure is not suited for
implementing "process-less async IO "- and kiovecs wont be able to help
that either. Unless we implement async, IRQ-driven bmap(), we'll always
need some sort of process context to set up IO.

	Ingo