From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agk3R-0004FG-6H for qemu-devel@nongnu.org; Thu, 17 Mar 2016 22:22:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agk3O-000733-0K for qemu-devel@nongnu.org; Thu, 17 Mar 2016 22:22:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agk3N-00072b-Oo for qemu-devel@nongnu.org; Thu, 17 Mar 2016 22:22:17 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 51666C00DE06 for ; Fri, 18 Mar 2016 02:22:17 +0000 (UTC) References: <1458033424-25414-1-git-send-email-wexu@redhat.com> <56EA52F0.3020703@redhat.com> <56EACB78.7030809@redhat.com> <20160317174339-mutt-send-email-mst@redhat.com> <56EAE1E8.4090006@redhat.com> From: Jason Wang Message-ID: <56EB6654.8030606@redhat.com> Date: Fri, 18 Mar 2016 10:22:12 +0800 MIME-Version: 1.0 In-Reply-To: <56EAE1E8.4090006@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [ Patch 0/2] Support Receive-Segment-Offload(RSC) for WHQL test of Window guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wei Xu , qemu-devel@nongnu.org On 03/18/2016 12:57 AM, Wei Xu wrote: > On 2016=E5=B9=B403=E6=9C=8817=E6=97=A5 23:44, Michael S. Tsirkin wrote: >> On Thu, Mar 17, 2016 at 11:21:28PM +0800, Wei Xu wrote: >>> >>> On 2016=E5=B9=B403=E6=9C=8817=E6=97=A5 14:47, Jason Wang wrote: >>>> On 03/15/2016 05:17 PM,wexu@redhat.com wrote: >>>>> From: Wei Xu >>>>> >>>>> Fixed issues based on rfc patch v2: >>>>> 1. Removed big param list, replace it with 'NetRscUnit' >>>>> 2. Different virtio header size >>>>> 3. Modify callback function to direct call. >>>>> 4. Needn't check the failure of g_malloc() >>>>> 5. Other code format adjustment, macro naming, etc >>>>> >>>>> This patch is to support WHQL test for Windows guest, while this >>>>> feature also >>>>> benifits other guest works as a kernel 'gro' like feature with >>>>> userspace implementation. >>>>> Feature information: >>>>> http://msdn.microsoft.com/en-us/library/windows/hardware/jj85332= 4 >>>>> >>>>> Both IPv4 and IPv6 are supported, though performance with >>>>> userspace virtio >>>>> is slow than vhost-net, there is about 1x to 3x performance >>>>> improvement to >>>>> userspace virtio, this is done by turning this feature on and disab= le >>>>> 'tso/gso/gro' on corresponding tap interface and guest interface, >>>>> while get >>>>> less improment with all these feature on. >>>>> >>>>> Test steps: >>>>> Although this feature is mainly used for window guest, i used >>>>> linux guest to help test >>>>> the feature, to make things simple, i used 3 steps to test the >>>>> patch as i moved on. >>>>> 1. With a tcp socket client/server pair running on 2 linux guest, >>>>> thus i can control >>>>> the traffic and debugging the code as i want. >>>>> 2. Netperf on linux guest test the throughput. >>>>> 3. WHQL test with 2 Windows guests. >>>>> >>>>> Current status: >>>>> IPv4 pass all the above tests. >>>>> IPv6 just passed test step 1 and 2 as described ahead, the virtio >>>>> nic cannot >>>>> receive any packet in WHQL test, looks like the test traffic is >>>>> not sent from >>>>> on the support machine, test device can access both host and >>>>> another linux >>>>> guest, tried a lot of ways to work it out but failed, maybe debug >>>>> from windows >>>>> guest driver side can help figuring it out. >>>> I think you need figure out where was the packet dropped first. If t= he >>>> packet was not dropped by windows guest, you may want to try >>>> dropmonitor. >>> Yes, there is something wrong with my previous description, i add >>> some debug >>> code and did new test, the packets are received by >>> virtio_net_receive() and >>> are finished putting to the vring with no error and sent to win guest >>> already, but wireshark on win guest doesn't get it, because the test >>> case >>> did some hacking on the filter, it installed another lightweight >>> filter, i'm >>> not sure how these packets go in the guest, maybe they are received b= ut >>> dropped by driver or stack, etc. >> Add some debug output in the driver, rebuild it and see packets >> as they are received and passed up the stack. > Yes, but this is to win guest, i tried to build a windows debug binary > but failed, is there any possible missing path in virtio between > pushed it to vring and notified the guest successfully? i'm sure at > this by debugging it with gdb. Is the packet always dropped or does it help if you turn off some configuration (e.g checksum offloads) works? >> >>> I tried 'dropmonitor', it's very interesting but it helps very >>> limitedly for >>> windows guest, i can only use it with qemu on the host. >>>>> Note: >>>>> A 'MessageDevice' nic chose as 'Realtek' will panic the system >>>>> sometimes during setup, >>>>> this can be figured out by replacing it with an 'e1000' nic. >>>>> >>>>> Todo: >>>>> More sanity check and tcp 'ecn' and 'window' scale test. >>>>> >>>>> Wei Xu (2): >>>>> virtio-net rsc: support coalescing ipv4 tcp traffic >>>>> virtio-net rsc: support coalescing ipv6 tcp traffic >>>>> >>>>> hw/net/virtio-net.c | 602 >>>>> ++++++++++++++++++++++++++++++++++++++++- >>>>> include/hw/virtio/virtio-net.h | 1 + >>>>> include/hw/virtio/virtio.h | 75 +++++ >>>>> 3 files changed, 677 insertions(+), 1 deletion(-) >>>>> > >