About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Wed, 24 May 2006

Netchannels. Initial benchmark.


Changed processing logic: receiving process context reads as much as possible (within given limit of 16 MTU sized frames)skbs from netchannel queue thus charging ACK sending and requeueing them into socket queue, and only then starts sk_receive_queue processing.

Initial benchmark.


Speed is the same, CPU usage is the same (socket CPU usage is 1% (or 20% :) more than netchannel one, but let's throw this away as some experimental error).

Netchannel was setup in copy_to_user mode, so it was not expected to be faster or eat less CPU, but main purpose of this test was to show that netchannels with all protocol processing moved to process' context can be at least that fast as when it is splitted into pieces. I've found some links in the web and blogs where developers completely disagree with VJ idea of moving stuff into process context... Well, this should break theirs mostly theoretical arguments.

It is clear that using memcpy setup numbers for netchannel are noticebly better than for sockets (see previous posted benchmarks).
I will start changing core networking code to accept different copying "actor" methods which will allow to use netchannels preallocated mapped area instead of copy_to_user().

Patches and userspace utilities can be found in archive.

/devel/networking :: Link / Comments ()