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

2006-06-08 Thread Evgeniy Polyakov
On Fri, Jun 09, 2006 at 01:00:24AM +0200, Hans Henrik Happe ([EMAIL PROTECTED]) 
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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2006-06-08 Thread Hans Henrik Happe
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?

H³  

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2006-06-08 Thread Evgeniy Polyakov
On Thu, Jun 08, 2006 at 09:15:55PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED]) 
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).
> 
> It is stable and 100% reproductible result.
> 
> Performance graph and patch are attached.

Hmm, graph has been attached now.

-- 
Evgeniy Polyakov


netchannel_speed.png
Description: PNG image


Netchannels: netchannel vs. socket. 2:0.

2006-06-08 Thread Evgeniy Polyakov
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).

It is stable and 100% reproductible result.

Performance graph and patch are attached.

Interesting note, that netchannel copy_to_user() setup slightly 
outperforms memcpy() setup.

I have some doubts that stock socket TCP code was used in Van Jacobson 
netchannel implementation, especially in the final benchmarks, because
of his words about userspace TCP processing, which sometimes pushes to read 
RFC 793 and do some coding...


Previous patches, userspace utility, design and implementatin details
can be found at project's homepage [1].

1. Netchannel homepage.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=netchannel

Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>

diff --git a/arch/i386/kernel/syscall_table.S b/arch/i386/kernel/syscall_table.S
index f48bef1..7a4a758 100644
--- a/arch/i386/kernel/syscall_table.S
+++ b/arch/i386/kernel/syscall_table.S
@@ -315,3 +315,5 @@ ENTRY(sys_call_table)
.long sys_splice
.long sys_sync_file_range
.long sys_tee   /* 315 */
+   .long sys_vmsplice
+   .long sys_netchannel_control
diff --git a/arch/x86_64/ia32/ia32entry.S b/arch/x86_64/ia32/ia32entry.S
index 5a92fed..fdfb997 100644
--- a/arch/x86_64/ia32/ia32entry.S
+++ b/arch/x86_64/ia32/ia32entry.S
@@ -696,4 +696,5 @@ ia32_sys_call_table:
.quad sys_sync_file_range
.quad sys_tee
.quad compat_sys_vmsplice
+   .quad sys_netchannel_control
 ia32_syscall_end:  
diff --git a/include/asm-i386/unistd.h b/include/asm-i386/unistd.h
index eb4b152..777cd85 100644
--- a/include/asm-i386/unistd.h
+++ b/include/asm-i386/unistd.h
@@ -322,8 +322,9 @@
 #define __NR_sync_file_range   314
 #define __NR_tee   315
 #define __NR_vmsplice  316
+#define __NR_netchannel_control317
 
-#define NR_syscalls 317
+#define NR_syscalls 318
 
 /*
  * user-visible error numbers are in the range -1 - -128: see
diff --git a/include/asm-x86_64/unistd.h b/include/asm-x86_64/unistd.h
index feb77cb..08c230e 100644
--- a/include/asm-x86_64/unistd.h
+++ b/include/asm-x86_64/unistd.h
@@ -617,8 +617,10 @@ __SYSCALL(__NR_tee, sys_tee)
 __SYSCALL(__NR_sync_file_range, sys_sync_file_range)
 #define __NR_vmsplice  278
 __SYSCALL(__NR_vmsplice, sys_vmsplice)
+#define __NR_netchannel_control279
+__SYSCALL(__NR_vmsplice, sys_netchannel_control)
 
-#define __NR_syscall_max __NR_vmsplice
+#define __NR_syscall_max __NR_netchannel_control
 
 #ifndef __NO_STUBS
 
diff --git a/include/linux/netchannel.h b/include/linux/netchannel.h
new file mode 100644
index 000..ed426e6
--- /dev/null
+++ b/include/linux/netchannel.h
@@ -0,0 +1,118 @@
+/*
+ * netchannel.h
+ * 
+ * 2006 Copyright (c) Evgeniy Polyakov <[EMAIL PROTECTED]>
+ * All rights reserved.
+ * 
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#ifndef __NETCHANNEL_H
+#define __NETCHANNEL_H
+
+#include 
+
+enum netchannel_commands {
+   NETCHANNEL_CREATE = 0,
+   NETCHANNEL_REMOVE,
+   NETCHANNEL_BIND,
+   NETCHANNEL_READ,
+   NETCHANNEL_DUMP,
+};
+
+enum netchannel_type {
+   NETCHANNEL_COPY_USER = 0,
+   NETCHANNEL_MMAP,
+   NETCHANEL_VM_HACK,
+};
+
+struct unetchannel
+{
+   __u32   src, dst;   /* source/destination 
hashes */
+   __u16   sport, dport;   /* source/destination 
ports */
+   __u8proto;  /* IP protocol number */
+   __u8type;   /* Netchannel type */
+   __u8memory_limit_order; /* Memor limit order */
+   __u8init_stat_work; /* Start statistic 
dumping */
+};
+
+struct unetchannel_control
+{
+   struct unetchannel  unc;
+   __u32   cmd;
+   __u32   len;