Re: [Qemu-devel] [ Patch 0/2] Support Receive-Segment-Offload(RSC) for WHQL test of Window guest

[Michael S. Tsirkin]

On Thu, Mar 17, 2016 at 11:21:28PM +0800, Wei Xu wrote:
> 
> 
> On 2016年03月17日 14:47, Jason Wang wrote:
> >On 03/15/2016 05:17 PM,address@hidden  wrote:
> >>From: Wei Xu<address@hidden>
> >>
> >>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/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 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 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.

> 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(-)
> >>