[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [ Patch 0/2] Support Receive-Segment-Offload(RSC) for W

From: Wei Xu
Subject: Re: [Qemu-devel] [ Patch 0/2] Support Receive-Segment-Offload(RSC) for WHQL test of Window guest
Date: Fri, 18 Mar 2016 00:57:12 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 2016年03月17日 23:44, Michael S. Tsirkin wrote:
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 
Feature information:

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 
1. With a tcp socket client/server pair running on 2 linux guest, thus i can 
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.
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.

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.
A 'MessageDevice' nic chose as 'Realtek' will panic the system sometimes during 
this can be figured out by replacing it with an 'e1000' nic.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]