From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUFpG-00080T-KJ for qemu-devel@nongnu.org; Mon, 22 Apr 2013 08:26:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUFpB-00054G-Qz for qemu-devel@nongnu.org; Mon, 22 Apr 2013 08:26:30 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:28378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUFpB-00052F-Kv for qemu-devel@nongnu.org; Mon, 22 Apr 2013 08:26:25 -0400 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MLN000E8OVRWV90@mailout3.w1.samsung.com> for qemu-devel@nongnu.org; Mon, 22 Apr 2013 13:26:18 +0100 (BST) Message-id: <51752C68.6030408@samsung.com> Date: Mon, 22 Apr 2013 16:26:16 +0400 From: Fedorov Sergey MIME-version: 1.0 References: <1366284715-10107-1-git-send-email-s.fedorov@samsung.com> <20130422114711.GA21317@stefanha-thinkpad.redhat.com> In-reply-to: <20130422114711.GA21317@stefanha-thinkpad.redhat.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] net/hub: remove can_receive handler List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: aliguori@us.ibm.com, a.basov@samsung.com, qemu-devel@nongnu.org, stefanha@redhat.com On 04/22/2013 03:47 PM, Stefan Hajnoczi wrote: > On Thu, Apr 18, 2013 at 03:31:55PM +0400, Sergey Fedorov wrote: >> Network hub should always receive incoming packets. Then forward them to >> the appropriate port queue and let the qemu_send_packet() do the right >> things. If the destination queue cannot receive the packet it will be >> appended to the queue. When the receiver call >> qemu_flush_queued_packets() later the queue will be really flushed and >> no packets will be stalled in the sender network queue. >> >> Signed-off-by: Sergey Fedorov >> --- >> net/hub.c | 20 -------------------- >> 1 file changed, 20 deletions(-) > What is the point of this change? There is no semantic difference for > well-behaved net clients. > > Does it fix a bug, if so, please include details? > > Stefan > > Yes, this fixes a bug. There were packet stalls when using user-mode networking with USB network device. slirp_output() calls qemu_send_packet() which eventually calls qemu_net_queue_send(). qemu_net_queue_send() calls qemu_can_send_packet(), which calls can_receive() callback of network hub. Then net_hub_port_can_receive() also calls qemu_can_send_packet() for each port except packet source port. Sometimes USB network device is not able to receive packet and qemu_can_send_packet() returns false. In my case there is no more ports and net_hub_port_can_receive() returns false. So qemu_net_queue_send() call qemu_net_queue_append() instead of qemu_net_queue_deliver(). qemu_net_queue_append() appends the packet to the receiving port of the network hub which is not flushed when USB netork device calls qemu_flush_queued_packets(). It is flushed only when slirp resend the packet by timeout. Actually there is no need in net_hub_port_can_receive() as the network hub can always receive packets and pass it to its port network clients with qemu_send_packet(). And if the destination port network client cannot receive the packet it will be queued in the *destination* port network client queue. Queued packets from that queue will be delivered as soon as the network client call qemu_flush_queued_packets(). -- Best regards, Sergey Fedorov, Junior Software Engineer, Samsung R&D Institute Rus. E-mail: s.fedorov@samsung.com