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

[Wei Xu]

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.

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