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,w...@redhat.com wrote: > >>>> >From: Wei Xu<w...@redhat.com> > >>>> > > >>>> >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
