Re: Status of AIO

[Phillip Susi <psusi@cfl.rr.com>]

David S. Miller wrote:
> I think something like net channels will be more effective on receive.

What is this "net channels"?  I'll do some googling but if you have a 
direct reference it would be helpful.

> We shouldn't be designing things for the old and inefficient world
> where the work is done in software and hardware interrupt context, it
> should be moved as close as possible to the compute entities and that
> means putting the work all the way into the app itself, if not very
> close.
>
> To me, it is not a matter of if we put the networking stack at least
> partially into some userland library, but when.

Maybe you should try using a microkernel then like mach?  The Linux way 
of doing things is to leave critical services that most user mode code 
depends on, such as filesystems and the network stack, in the kernel.  I 
don't think that's going to change.

> Eveyone has their brains wrapped around how OS support for networking
> has always been done, and assuming that particular model is erroneous
> (and net channels show good hard evidence that it is) this continued
> thought process merely continues the error.

Have you taken a look at bsd's kqueue and NT's IO completion port 
approach?  They allow virtually all of the IO to be offloaded to 
hardware DMA, and there's no reason Linux can't do the same with aio and 
O_DIRECT.  There's no need completely throw out the stack and start 
over, let alone in user mode, to get there.

> I really dislike it when non-networking people work on these
> interfaces.  They've all frankly stunk, and they've had several
> opportunities to try and get it right.

I agree, the old (non) blocking IO style interfaces have all sucked, 
which is why it's time to move on to aio.  NT has been demonstrating for 
10 years now ( that's how long ago I wrote an FTPd using IOCPs on NT ) 
the benefits of async IO.  It has been a long time coming, but once the 
Linux kernel is capable of zero copy aio, I will be quite happy.

> I want a bonafide networking person to work on any high performance
> networking API we every decide to actually use.
>
> This is why I going to sit and wait patiently for Van Jacobson's work
> to get published and mature, because it's the only light in the tunnel
> since Multics.
>
> Yes, since Multics, that's how bad the existing models for doing these
> things are.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/