From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbVJ8-0003FN-Ig for qemu-devel@nongnu.org; Wed, 30 Oct 2013 08:55:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VbVJ3-0007vt-7v for qemu-devel@nongnu.org; Wed, 30 Oct 2013 08:55:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbVJ2-0007vm-Ug for qemu-devel@nongnu.org; Wed, 30 Oct 2013 08:55:29 -0400 Date: Wed, 30 Oct 2013 13:55:17 +0100 From: Stefan Hajnoczi Message-ID: <20131030125517.GA21286@stefanha-thinkpad.redhat.com> References: <20130422114711.GA21317@stefanha-thinkpad.redhat.com> <51752C68.6030408@samsung.com> <20130422145749.GA28049@stefanha-thinkpad.redhat.com> <517556D9.2080809@samsung.com> <20130423065841.GA6447@stefanha-thinkpad.redhat.com> <51763B36.1000701@samsung.com> <20130423120021.GC2431@stefanha-thinkpad.redhat.com> <526513AE.2050605@samsung.com> <20131029145542.GA1929@stefanha-thinkpad.redhat.com> <5270DF6C.2070404@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5270DF6C.2070404@samsung.com> Subject: Re: [Qemu-devel] [PATCH] net/hub: remove can_receive handler List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fedorov Sergey Cc: Stefan Hajnoczi , Luigi Rizzo , a.basov@samsung.com, qemu-devel@nongnu.org, Anthony Liguori On Wed, Oct 30, 2013 at 02:29:00PM +0400, Fedorov Sergey wrote: > On 10/29/2013 06:55 PM, Stefan Hajnoczi wrote: > >On Mon, Oct 21, 2013 at 03:44:46PM +0400, Fedorov Sergey wrote: > >>After our discussion about this patch I decided to keep my patch in > >>our branch until rebase onto a new release. Recently I have rebased > >>our branch onto v1.5.3 and reverted my patch. Then I face an issue > >>when using user-mode networking with USB network device for mounting > >>root file system through NFS. Fragmented UDP packets from host to > >>guest does not handled properly. Seems that some fragments is lost > >>or somehow stalled. See guest tcpdump log below. > >> > >>03:16:52.259690 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], > >>proto UDP (17), length 164) > >> 10.0.2.15.3369105030 > 10.0.2.2.nfs: 136 readdirplus fh Unknown/0100070004001200000000002873593C9B3C43388E23748B0BAD870C00000000 > >>512 bytes @ 0 max 4096 verf 0000000000000000 > >>03:16:52.262323 IP (tos 0x0, ttl 64, id 16, offset 0, flags [+], > >>proto UDP (17), length 1500) > >> 10.0.2.2.nfs > 10.0.2.15.3369105030: reply ok 1472 readdirplus > >>POST: DIR 40777 ids 0/0 sz 4096 verf 0000000000000000 > >>03:16:52.264592 IP (tos 0x0, ttl 64, id 16, offset 1480, flags [+], > >>proto UDP (17), length 1500) > >> 10.0.2.2 > 10.0.2.15: udp > >>03:16:54.462961 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], > >>proto UDP (17), length 164) > >> 10.0.2.15.3369105030 > 10.0.2.2.nfs: 136 readdirplus fh Unknown/0100070004001200000000002873593C9B3C43388E23748B0BAD870C00000000 > >>512 bytes @ 0 max 4096 verf 0000000000000000 > >>03:16:54.466300 IP (tos 0x0, ttl 64, id 17, offset 0, flags [+], > >>proto UDP (17), length 1500) > >> 10.0.2.2.nfs > 10.0.2.15.3369105030: reply ok 1472 readdirplus > >>POST: DIR 40777 ids 0/0 sz 4096 verf 0000000000000000 > >>03:16:54.467084 IP (tos 0x0, ttl 64, id 17, offset 1480, flags [+], > >>proto UDP (17), length 1500) > >> 10.0.2.2 > 10.0.2.15: udp > >>... > >> > >>I didn't investigate the cause of the problem in detail. I just reverted > >> > >>commit 199ee608f0d08510b5c6c37f31a7fbff211d63c4 > >>Author: Luigi Rizzo > >>Date: Tue Feb 5 17:53:31 2013 +0100 > >> > >> net: fix qemu_flush_queued_packets() in presence of a hub > >> > >>And then applied my patch. After that everything works fine for me. > >>See guest tcpdump log below. > >> > >>04:45:15.897245 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], > >>proto UDP (17), length 164) > >> 10.0.2.15.3642011847 > 10.0.2.2.nfs: 136 readdirplus fh Unknown/0100070004001200000000002873593C9B3C43388E23748B0BAD870C00000000 > >>512 bytes @ 0 max 4096 verf 0000000000000000 > >>04:45:15.899686 IP (tos 0x0, ttl 64, id 15, offset 0, flags [+], > >>proto UDP (17), length 1500) > >> 10.0.2.2.nfs > 10.0.2.15.3642011847: reply ok 1472 readdirplus > >>POST: DIR 40777 ids 0/0 sz 4096 verf 0000000000000000 > >>04:45:15.906253 IP (tos 0x0, ttl 64, id 15, offset 1480, flags [+], > >>proto UDP (17), length 1500) > >> 10.0.2.2 > 10.0.2.15: udp > >>04:45:15.906687 IP (tos 0x0, ttl 64, id 15, offset 2960, flags > >>[none], proto UDP (17), length 240) > >> 10.0.2.2 > 10.0.2.15: udp > >> > >>So there must be something wrong with already applied patch. What > >>could you suggest? > >The next step is to investigate the cause. > > > >Perhaps hw/usb/dev-network.c:usb_net_handle_datain() is not calling > >qemu_flush_queued_packets() every time in_buf[] is read completely. > >This if statement looks strange to me: > > > >if (s->in_ptr >= s->in_len && > > (is_rndis(s) || (s->in_len & (64 - 1)) || !len)) { > > /* no short packet necessary */ > > usb_net_reset_in_buf(s); > >} > > > >Try placing printfs to find out whether qemu_flush_queued_packets() is > >getting called when you see packet loss. > > > >Stefan > > > > Seems that I have figured out the problem. net_hub_flush() does not > flush source port. And qemu_flush_queued_packets() also returns > after calling net_hub_flush(). So I think the problem is that > neither qemu_flush_queued_packets() nor net_hub_flush() call > qemu_net_queue_flush() for the source port. So I think it sould be > fixed in qemu_flush_queued_packets() by removing the return > statement after calling net_hub_flush(). That fix does work for me. > So I could submit that patch after getting permission for that. Sounds good to me. I have CCed Luigi in case he wants to comment. Stefan