From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bcjY8-0008EU-1h for qemu-devel@nongnu.org; Wed, 24 Aug 2016 21:33:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bcjY3-0008LS-Bb for qemu-devel@nongnu.org; Wed, 24 Aug 2016 21:33:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bcjY3-0008LB-5r for qemu-devel@nongnu.org; Wed, 24 Aug 2016 21:33:39 -0400 Date: Wed, 24 Aug 2016 21:33:34 -0400 From: "Daniel P. Berrange" Message-ID: <20160825013334.GH22605@redhat.com> Reply-To: "Daniel P. Berrange" References: <47CEA9C0E570484FBF22EF0D7EBCE5B5357D7C69@szxema505-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <47CEA9C0E570484FBF22EF0D7EBCE5B5357D7C69@szxema505-mbx.china.huawei.com> Subject: Re: [Qemu-devel] A question about this commit 9894dc0cdcc397ee5b26370bc53da6d360a363c2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gaohaifeng (A)" Cc: "pbonzini@redhat.com" , "Lilijun (Jerry)" , zangchuanqiang , qemu devel On Tue, Aug 23, 2016 at 08:57:44AM +0000, Gaohaifeng (A) wrote: > Hi Daniel & Paolo, > > Commit 9894dc0c "char: convert from GIOChannel to QIOChannel", about > > the below code segment: > > -static gboolean tcp_chr_read(GIOChannel *chan, GIOCondition cond, void *opaque) > +static gboolean tcp_chr_read(QIOChannel *chan, GIOCondition cond, void *opaque) > { > CharDriverState *chr = opaque; > TCPCharDriver *s = chr->opaque; > @@ -2938,9 +2801,7 @@ static gboolean tcp_chr_read(GIOChannel *chan, GIOCondition cond, void *opaque) > if (len > s->max_size) > len = s->max_size; > size = tcp_chr_recv(chr, (void *)buf, len); > - if (size == 0 || > - (size < 0 && > - socket_error() != EAGAIN && socket_error() != EWOULDBLOCK)) { > + if (size == 0 || size == -1) { > /* connection closed */ > tcp_chr_disconnect(chr); > } else if (size > 0) { > > The old version will not call tcp_chr_disconnect when error is not > EAGAIN. > The new version will call tcp_chr_disconnect when size==-1. From the > tcp_chr_recv function we see EAGIN will return -1, so EAGIN will call > tcp_chr_disconnect. > > We meet an issue when Guest VM use DPDK(1.6.0) l2fwd, it may exit since > link status is not up. The link is down because tcp_chr_disconnect will > set it. > > Can you explain it why EAGIN here changes the behavior ? tcp_chr_read is used in a call to io_add_watch_poll() which sets up an event loop watch so that tcp_chr_read is called when there is incoming data to be read. IOW, when tcp_chr_read is invoked, I would always expect that at least 1 byte is available, and so EAGAIN should not occurr. So I'm puzzled why you would get EAGAIN at all, unless there is some kind of race with other code also consuming bytes from the same socket. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|