I was trying to run GDB remote debug tests through a -redir socket
today. It crawled unbelievably. Paul guessed that slirp wasn't using
TCP_NODELAY, and Nagle was to blame.
He was even righter than usual. Adding TCP_NODELAY speeds up this
particular workload by (very approximately) 54x. See trivial attached
patch.
Is this going to bite other things, i.e. does it need to be
configurable?
--
Daniel Jacobowitz
CodeSourcery
---
slirp/tcp.h | 2 +-
slirp/tcp_subr.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
Index: qemu/slirp/tcp.h
===================================================================
--- qemu.orig/slirp/tcp.h 2006-11-13 14:25:24.000000000 -0500
+++ qemu/slirp/tcp.h 2006-11-13 14:25:29.000000000 -0500
@@ -112,7 +112,7 @@ struct tcphdr {
/*
* User-settable options (used with setsockopt).
*/
-/* #define TCP_NODELAY 0x01 */ /* don't delay send to coalesce packets
*/
+#define TCP_NODELAY 0x01 /* don't delay send to coalesce packets
*/
/* #define TCP_MAXSEG 0x02 */ /* set maximum segment size */
/*
Index: qemu/slirp/tcp_subr.c
===================================================================
--- qemu.orig/slirp/tcp_subr.c 2006-11-13 14:22:34.000000000 -0500
+++ qemu/slirp/tcp_subr.c 2006-11-13 14:23:31.000000000 -0500
@@ -499,6 +499,8 @@ tcp_connect(inso)
setsockopt(s,SOL_SOCKET,SO_REUSEADDR,(char *)&opt,sizeof(int));
opt = 1;
setsockopt(s,SOL_SOCKET,SO_OOBINLINE,(char *)&opt,sizeof(int));
+ opt = 1;
+ setsockopt(s,IPPROTO_TCP,TCP_NODELAY,(char *)&opt,sizeof(int));
so->so_fport = addr.sin_port;
so->so_faddr = addr.sin_addr;
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
