Re: [Qemu-devel] [4341] qemu: generate signals on tap I/O

[Anthony Liguori <anthony@codemonkey.ws>]

Aurelien Jarno wrote:
> Revision: 4341
>           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=4341
> Author:   aurel32
> Date:     2008-05-05 21:26:43 +0000 (Mon, 05 May 2008)
>
> Log Message:
> -----------
> qemu: generate signals on tap I/O
>
> Currently tap does not generate signals on I/O; this causes
> network latency to be dependent on the timer tick (1ms without
> dyntick, guest dependent with dyntick).  By generating a signal
> on I/O, we can inform the guest immediately that a packet has
> arrived.
>
> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
>
> Modified Paths:
> --------------
>     trunk/vl.c
>
> Modified: trunk/vl.c
> ===================================================================
> --- trunk/vl.c	2008-05-05 21:26:31 UTC (rev 4340)
> +++ trunk/vl.c	2008-05-05 21:26:43 UTC (rev 4341)
> @@ -4030,6 +4030,7 @@
>      if (!s)
>          return NULL;
>      s->fd = fd;
> +    enable_sigio_timer(fd);
>      s->vc = qemu_new_vlan_client(vlan, tap_receive, NULL, s);
>      qemu_set_fd_handler(s->fd, tap_send, NULL, s);
>      snprintf(s->vc->info_str, sizeof(s->vc->info_str), "tap: fd=%d", fd);
>   

I still haven't seen anyone explain why this results in a performance 
improvement.  The SIGIO handler is tied to the host_alarm_handler which 
will not dispatch IO.  It surprises me that it has any affect at all.

FWIW, we're getting rid of SIGIO in KVM.  It doesn't improve performance 
verses a properly implemented select lop.

Regards,

Anthony Liguori

>
>
>