From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agbEd-0005vS-6U for qemu-devel@nongnu.org; Thu, 17 Mar 2016 12:57:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agbEZ-00062k-VC for qemu-devel@nongnu.org; Thu, 17 Mar 2016 12:57:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60726) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agbEZ-00062g-Nl for qemu-devel@nongnu.org; Thu, 17 Mar 2016 12:57:15 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 2ED65C050055 for ; Thu, 17 Mar 2016 16:57:15 +0000 (UTC) Received: from wei-thinkpad.nay.redhat.com (vpn1-7-24.pek2.redhat.com [10.72.7.24]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2HGvCWd022527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Mar 2016 12:57:14 -0400 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> From: Wei Xu Message-ID: <56EAE1E8.4090006@redhat.com> Date: Fri, 18 Mar 2016 00:57:12 +0800 MIME-Version: 1.0 In-Reply-To: <20160317174339-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed 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: qemu-devel@nongnu.org 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 fea= ture also >>>> benifits other guest works as a kernel 'gro' like feature with users= pace implementation. >>>> Feature information: >>>> 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 improvem= ent to >>>> userspace virtio, this is done by turning this feature on and disabl= e >>>> 'tso/gso/gro' on corresponding tap interface and guest interface, wh= ile 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, th= us 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 ni= c 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 fr= om windows >>>> guest driver side can help figuring it out. >>> I think you need figure out where was the packet dropped first. If th= e >>> packet was not dropped by windows guest, you may want to try dropmoni= tor. >> 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 c= ase >> did some hacking on the filter, it installed another lightweight filte= r, i'm >> not sure how these packets go in the guest, maybe they are received bu= t >> 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=20 but failed, is there any possible missing path in virtio between pushed=20 it to vring and notified the guest successfully? i'm sure at this by=20 debugging it with gdb. > >> I tried 'dropmonitor', it's very interesting but it helps very limited= ly for >> windows guest, i can only use it with qemu on the host. >>>> Note: >>>> A 'MessageDevice' nic chose as 'Realtek' will panic the system somet= imes 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(-) >>>>