[Qemu-devel] TCP_NODELAY for -redir

[Qemu-devel] TCP_NODELAY for -redir

[Daniel Jacobowitz]

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;

Re: [Qemu-devel] TCP_NODELAY for -redir

[Daniel Jacobowitz]

On Mon, Nov 13, 2006 at 02:30:27PM -0500, Daniel Jacobowitz wrote:
> 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?

No comments on this...

My reasoning, by the way, was that slirp is being used as a TCP-to-TCP
gateway.  I think that if we were to use nagle here, we'd end up doing
it twice: once at the sender inside the guest, and once again on the
host's TCP stack.  Using TCP_NODELAY lets the guest take
responsibility.


-- 
Daniel Jacobowitz
CodeSourcery

[Qemu-devel] PPC Bug Report - Trap Exception setting SRR0 incorrectly

[Ely Soto]

[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]

PPC Bug Only

Call Stack

op_helper.c : do_tw()
op_helper.c : do_raise_exception_err()
op_helper.c : cpu_loop_exit()
op_helper.c : longjmp()
???
helper.c : do_interrupt()

Normally when an exception gets to do_interrupt(), env->nip is set to the 
instruction after the one causing the exception.
However, a trap instruction arrives at the do_interrupt() with the 
env->nip set at the instruction that caused the exception.
This causes an the SRR0 to get set incorrectly to one instruction back 
when calling the exception handler.

I'm still learning the code so I'm still trying to figure out the right 
fix since
its possible that more exceptions are affected. I've already verified that 
forcing the env->nip forward for just the trap case
fixes the execution.

>From the middle of helper.c : do_interrupt()
....
case EXCP_TRAP:
....
goto store_current;
....

>From the bottom of helper.c : do_interrupt()
....
    store_current:
        /* save current instruction location */
        *srr_0 = (env->nip - 4) & 0xFFFFFFFFULL;
        break;
    store_next:
        /* save next instruction location */
        *srr_0 = env->nip & 0xFFFFFFFFULL;
        break;
....


I discovered this because I'm trying to get a vxworks debugger working 
when the os is running.
Ohh ya, I've got a VxWorks 6.3 kernel up and running on PPC QEMU. 8-) 
Custom BSP and all.


-----------------------------------------
Notice:  This e-mail is intended solely for use of the individual
or entity to which it is addressed and may contain information that
is proprietary, privileged and exempt from disclosure under
applicable law.  If the reader is not the intended recipient or
agent responsible for delivering the message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly
prohibited.  This communication may also contain data subject to
U.S. export laws.  If so, that data subject to the International
Traffic in Arms Regulation cannot be disseminated, distributed or
copied to foreign nationals, residing in the U.S. or abroad, absent
the express prior approval of the U.S. Department of State.   If
you have received this communication in error, please notify the
sender by reply e-mail and destroy the e-mail message and any
physical copies made of the communication.  Thank you.

[-- Attachment #2: Type: text/html, Size: 4403 bytes --]

Re: [Qemu-devel] TCP_NODELAY for -redir

[Daniel Jacobowitz]

On Mon, Nov 13, 2006 at 02:30:27PM -0500, Daniel Jacobowitz wrote:
> 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.

Ping.  I still think this patch is a good idea for the reasons
previously explained.

> 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;
> 
> 

-- 
Daniel Jacobowitz
CodeSourcery

RE: [Qemu-devel] TCP_NODELAY for -redir

[Wessel, Jason]

I am in total agreement with the change. :-)

Jason. 

> -----Original Message-----
> From: 
> qemu-devel-bounces+jason.wessel=windriver.com@nongnu.org 
> [mailto:qemu-devel-bounces+jason.wessel=windriver.com@nongnu.o
> rg] On Behalf Of Daniel Jacobowitz
> Sent: Thursday, November 16, 2006 8:44 PM
> To: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] TCP_NODELAY for -redir
> 
> On Mon, Nov 13, 2006 at 02:30:27PM -0500, Daniel Jacobowitz wrote:
> > 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?
> 
> No comments on this...
> 
> My reasoning, by the way, was that slirp is being used as a 
> TCP-to-TCP gateway.  I think that if we were to use nagle 
> here, we'd end up doing it twice: once at the sender inside 
> the guest, and once again on the host's TCP stack.  Using 
> TCP_NODELAY lets the guest take responsibility.
> 
> 
> --
> Daniel Jacobowitz
> CodeSourcery
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>