qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [ RFC Patch v5 0/2] Support Receive-Segment-Offload(RSC


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [ RFC Patch v5 0/2] Support Receive-Segment-Offload(RSC) for WHQL
Date: Wed, 25 May 2016 11:26:52 +0300

On Wed, May 25, 2016 at 04:08:50PM +0800, Jason Wang wrote:
> 
> 
> On 2016年05月24日 16:26, Michael S. Tsirkin wrote:
> >On Tue, May 24, 2016 at 04:03:04PM +0800, Jason Wang wrote:
> >>>
> >>>
> >>>On 2016年05月24日 04:14,address@hidden  wrote:
> >>>> >From: Wei Xu<address@hidden>
> >>>> >
> >>>> >Changes in V5:
> >>>> >- Passed all IPv4/6 test cases
> >>>> >- Add new fields in 'virtio_net_hdr'
> >>>> >- Set 'gso_type' & 'coalesced packets' in new field.
> >>>> >- Bypass all 'tcp option' packet
> >>>> >- Bypass all 'pure ack' packet
> >>>> >- Bypass all 'duplicate ack' packet
> >>>> >- Change 'guest_rsc' feature bit to 'false' by default
> >>>> >- Feedbacks from v4, typo, etc.
> >>>
> >>>Patch does not apply on master ...
> >>>
> >>>> >
> >>>> >Note:
> >>>> >There is still a few pending issues about the feature bit, and need to 
> >>>> >be
> >>>> >discussed with windows driver maintainer, so linux guests with this 
> >>>> >patch
> >>>> >won't work at current, haven't figure it out yet, but i'm guessing it's
> >>>> >caused by the 'gso_type' is set to 'VIRTIO_NET_HDR_GSO_TCPV4/6',
> >>>> >will fix it after get the final solution, the below test steps and
> >>>> >performance data is based on v4.
> >>>
> >>>Can we split the patches into smaller ones to make review or merging 
> >>>easier?
> >>>E.g can we send the patches without any feature negotiation and vnet header
> >>>extension?
> >>>
> >>>We can focus on the coalescing (maybe ipv4) without any guest involvement 
> >>>in
> >>>this series. In this way, the issues were limited and can be converged 
> >>>soon.
> >>>After this has been merged, we can add patches that co-operate with guests
> >>>on top (since it needs agreement on virtio specs). Does this sounds a good
> >>>plan?
> >True but disabling everything when feature is not negotiated
> >reduces the risk somewhat.
> >
> 
> Yes, but I believe we can only merge the patch with new virtio features
> after they were accepted by spec?

Spec acceptance takes a lot of time. I think it's required to send
proposal to virtio tc and to give a week or two for people
to comment, but if there are no comments I don't think
we must hold up code.

I am interested in hearing whether new fields should be added to
all packets, or rather to packets with a specific bit set in
flags or gso_type field.

-- 
MST



reply via email to

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