From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAyDJ-00076h-Kd for qemu-devel@nongnu.org; Fri, 03 Jul 2015 06:28:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZAyDD-0000KA-QZ for qemu-devel@nongnu.org; Fri, 03 Jul 2015 06:28:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAyDD-0000K0-J5 for qemu-devel@nongnu.org; Fri, 03 Jul 2015 06:28:51 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id BC8BBBF9C5 for ; Fri, 3 Jul 2015 10:28:50 +0000 (UTC) Date: Fri, 3 Jul 2015 11:28:47 +0100 From: Stefan Hajnoczi Message-ID: <20150703102847.GA15599@stefanha-thinkpad.redhat.com> References: <1435631360-4978-1-git-send-email-famz@redhat.com> <20150702133057.GI21214@stefanha-thinkpad.home> <20150703004215.GA19093@ad.nay.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <20150703004215.GA19093@ad.nay.redhat.com> Subject: Re: [Qemu-devel] [PATCH for-2.4] net-hub: Drop can_receive List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Jason Wang , qemu-devel@nongnu.org --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 03, 2015 at 08:42:15AM +0800, Fam Zheng wrote: > On Thu, 07/02 14:30, Stefan Hajnoczi wrote: > > On Tue, Jun 30, 2015 at 10:29:20AM +0800, Fam Zheng wrote: > > > It returns true as long as there is another attached port. This is not > > > strictly necessary because even if there is only one port (the sender= ), > > > net_hub_port_receive could succeed with a NOP. So always deliver the > > > packets, instead of queuing them. > > >=20 > > > This fixes the possible hanging issue after net layer changed how > > > can_read is handled. That is, if net_hub_port_can_receive returned > > > false, the peer would disable the queue until it's explicitly flushed > > > (for example, a call to qemu_flush_queued_packets() in net_hub_add_po= rt, > > > where net_hub_port_can_receive() would become true). This patch avoids > > > that complication. > > >=20 > > > Signed-off-by: Fam Zheng > > > --- > > > net/hub.c | 20 -------------------- > > > 1 file changed, 20 deletions(-) > >=20 > > Hmm...I misread the hub code: > >=20 > > net_hub_port_can_receive() returns true if *any* port can receive. > >=20 > > net_hub_receive_iov() always accepts packets. It never discards or > > queues. > >=20 > > So in order to move to the semantics you want, let's drop > > net_hub_port_can_receive() *and* change net_hub_receive_iov(): > >=20 > > static ssize_t net_hub_receive(NetHub *hub, NetHubPort *source_port, > > const uint8_t *buf, size_t len) > > { > > NetHubPort *port; > >=20 > > QLIST_FOREACH(port, &hub->ports, next) { > > if (port =3D=3D source_port) { > > continue; > > } > >=20 > > /* No need for a callback because net_hub_flush() is called > > * when the peer flushes the queue anyway. > > * > > * Note that packets are duplicated if there are multiple > > * ports and some of them accepted a packet before a later > > * port queued it. Live with it, the network tolerates > > * duplicates. > > */ > > if (qemu_send_packet(&port->nc, buf, len) =3D=3D 0) { > > return 0; >=20 > I'm not sure if it is a good idea to return 0 from either net_hub_port_re= ceive > or net_hub_receive. Because that way if one out of ten ports is down, oth= er > ones will no longer get more packets from tap. You are right, in order to carry over existing semantics it needs to return 0 when all ports returned 0. That way .can_receive has been eliminated but behavior is identical except for duplicate packets, which can happen on the network anyway. --9amGYk9869ThD9tj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVlmPfAAoJEJykq7OBq3PIPlAIALNi0xpnUmeSlBnAUSbcS/g3 eRzarpzmNqHPV1fAETW2xlq7WABCdCZjnYOZutjJ6oVq+XNR16jkiAZavINFoCUv LCGCdMRsiteLNynUI2qFYkSDzYCJz7smLPAAAkDbiyY+qOYcY64vKSXpljUjcC3V RcaDztpSHyJDot8jISiZhkeUcsm2NegHYScMXmp6l4GFKnIL5rccpSUTGTnXqvOV BAOXGtKAe6U30rlPG5UsDz7tmyMotd3jhk2IAdsFoS3P6X3Nh2BAF36XXOY2+Rtt l1iGaEZfovXjVVquGk5QZDp8t7CpxZwxAAOcwa0BysJSiQPGnIiII8gMyHLNqc4= =DW9M -----END PGP SIGNATURE----- --9amGYk9869ThD9tj--