From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5LEJ-00043G-MR for qemu-devel@nongnu.org; Fri, 02 Aug 2013 15:41:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V5LEA-0003Bn-VZ for qemu-devel@nongnu.org; Fri, 02 Aug 2013 15:41:39 -0400 Received: from mout.web.de ([212.227.17.11]:60624) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5LEA-0003Ap-Kl for qemu-devel@nongnu.org; Fri, 02 Aug 2013 15:41:30 -0400 Received: from mchn199C.mchp.siemens.de ([95.157.58.223]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0MduMb-1UgOl32ke5-00PaVv for ; Fri, 02 Aug 2013 21:41:28 +0200 Message-ID: <51FC0B64.9080700@web.de> Date: Fri, 02 Aug 2013 21:41:24 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <51FA97CA.7050905@siemens.com> <20130802114652.GA342@stefanha-thinkpad.redhat.com> <51FBA9FE.9050505@siemens.com> In-Reply-To: <51FBA9FE.9050505@siemens.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jegCNalkPx20bQ1CUsOjfxKgLG9K9QB9o" Subject: Re: [Qemu-devel] net/tap.c: Possibly a way to stall tap input List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qemu-devel , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jegCNalkPx20bQ1CUsOjfxKgLG9K9QB9o Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-08-02 14:45, Jan Kiszka wrote: > On 2013-08-02 13:46, Stefan Hajnoczi wrote: >> On Thu, Aug 01, 2013 at 07:15:54PM +0200, Jan Kiszka wrote: >>> I was digging into the involved code and found something fishy: >>> >>> net/tap.c: >>> static void tap_send(void *opaque) >>> { >>> ... >>> size =3D qemu_send_packet_async(&s->nc, buf, size, >>> tap_send_completed); >>> if (size =3D=3D 0) { >>> tap_read_poll(s, false); >>> } >>> >>> So, if tap_send is registered for the mainloop polling (ie. can_recei= ve >>> returned true before starting to poll) but qemu_send_packet_async >>> returns 0 now as qemu_can_send_packet/can_receive happens to report >>> false in the meantime, we will disable read polling. If also write >>> polling is off, the fd will be completely removed from the iohandler >>> list. But even if write polling remains on, I wonder what should brin= g >>> read polling back? >> >> This behavior seems fine to me. Once the peer (pcnet) is able to >> receive again it must flush the queue, this will re-enable >> tap_read_poll(). >> >> Can you explain a bit more why this would be a problem? >=20 > The problem is that I don't see at all what will call tap_read_poll(s, > 1), neither in theory nor in reality. >=20 > As long as the real test case is out of reach, I tried to emulate the > faulty behaviour by letting tap_can_send always return 1. Result: > reception stalls during boot as even qemu_flush_queued_packets cannot > get it running again once tap_read_poll(s, 0) was called. OK, false alarm. The issue was most likely fixed by commit 199ee608 (net: fix qemu_flush_queued_packets() in presence of a hub) which is present in 1.5.x but not 1.3.x. We initially tried to test on 1.5 but had to role back to 1.3 due to other issues - and missed this fix. My understanding of the networking maze was confused by the unfortunate naming of the incoming net client queues ("send_queue") - will propose a renaming. This still requires a confirmation on the target, but I'm quite optimistic now. Jan --jegCNalkPx20bQ1CUsOjfxKgLG9K9QB9o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlH8C2cACgkQitSsb3rl5xR8VACfePKPtoNjkz6cdgNDVThiY/PZ 9r4AoKYCHQd0GUYQ37scNioJxoLivhOa =jrqE -----END PGP SIGNATURE----- --jegCNalkPx20bQ1CUsOjfxKgLG9K9QB9o--