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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
