Re: Netchannels: netchannel vs. socket. 2:0.

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

On Fri, Jun 09, 2006 at 01:00:24AM +0200, Hans Henrik Happe (hhh@imada.sdu.dk) wrote:
> On Thursday 08 June 2006 19:15, you wrote:
> > After some enhancements made for netchannel subsystem I'm pleased to
> > announce, that netchannel subsystem outperforms existing layered design
> > both in CPU usage and network speed.
> > 
> > Well, after such pretentious introduction I want to cool things down.
> > CPU usage is about 1-2% less for netchannels and network performance is
> > about 1-2 MB higher and sometimes exceeds 84 MB/sec which, I think, 
> > is maximum for given network setup (e1000 receive, r8169 send, 1500 MTU).
> 
> I have followed your work closely and have wondered how it affects latency?
> I have somewhat limited knowledge about TCP and how the kernel handles it, but 
> I guess the path from NIC to userspace hasn't increased. What about syscall 
> overhead caused by userspace TCP processing?

Path from NIC to userspace was decreased in that way that there are less
number of context switches, much smaller amount of work being done in
softirq (I have not modified driver and still use NAPI), less cache
thrashing due to work ping-ponging and less number of locks.
Number of syscalls is still the same - either one recv() or one
netchannel_control() to read the same block of data.

But since existing socket code is used, gain is not that big, since
sockets are locked, although they should not, skbs are requeued, ACKs
are scheduled, although all that could be changed.

At least receiving part of the netchannel TCP processing could be
different. And my thoughts move in that direction.

> H³  

-- 
	Evgeniy Polyakov