From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60756) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agmr2-0002eB-NF for qemu-devel@nongnu.org; Fri, 18 Mar 2016 01:21:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agmqz-0003g5-Gt for qemu-devel@nongnu.org; Fri, 18 Mar 2016 01:21:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agmqz-0003fM-91 for qemu-devel@nongnu.org; Fri, 18 Mar 2016 01:21:41 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id E482B461DA for ; Fri, 18 Mar 2016 05:21:40 +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> <56EB6654.8030606@redhat.com> <56EB82E5.3090204@redhat.com> From: Jason Wang Message-ID: <56EB9065.20503@redhat.com> Date: Fri, 18 Mar 2016 13:21:41 +0800 MIME-Version: 1.0 In-Reply-To: <56EB82E5.3090204@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:24 PM, Wei Xu wrote: > > > On 2016=E5=B9=B403=E6=9C=8818=E6=97=A5 10:22, Jason Wang wrote: >> >> 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 wrot= e: >>>> 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: >>>>>>> =20 >>>>>>> http://msdn.microsoft.com/en-us/library/windows/hardware/jj853324 >>>>>>> >>>>>>> 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 >>>>>>> disable >>>>>>> '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 the >>>>>> 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 gue= st >>>>> already, but wireshark on win guest doesn't get it, because the tes= t >>>>> 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 but >>>>> 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 binar= y >>> 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? > Yes, only the test packets are dropped, there is no checksum for ipv6 > header, > i remembered i disabled checksum offloads and changed other features(RS= S) > in the guest but it doesn't help, is there any other tunable values > for qemu?=20 -device virtio-net-pci,? can gives you all the properties.