From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5U9c-0004uF-MD for qemu-devel@nongnu.org; Wed, 25 May 2016 04:27:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b5U9Y-0006Rq-El for qemu-devel@nongnu.org; Wed, 25 May 2016 04:26:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5U9Y-0006Rj-9J for qemu-devel@nongnu.org; Wed, 25 May 2016 04:26:56 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 58F268B11B for ; Wed, 25 May 2016 08:26:55 +0000 (UTC) Date: Wed, 25 May 2016 11:26:52 +0300 From: "Michael S. Tsirkin" Message-ID: <20160525112140-mutt-send-email-mst@redhat.com> References: <1464034485-30543-1-git-send-email-wexu@redhat.com> <57440AB8.604@redhat.com> <20160524112527-mutt-send-email-mst@redhat.com> <57455D92.3080008@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <57455D92.3080008@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [ RFC Patch v5 0/2] Support Receive-Segment-Offload(RSC) for WHQL List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang Cc: victork@redhat.com, yvugenfi@redhat.com, qemu-devel@nongnu.org, wexu@redhat.com, marcel@redhat.com, dfleytma@redhat.com On Wed, May 25, 2016 at 04:08:50PM +0800, Jason Wang wrote: >=20 >=20 > On 2016=E5=B9=B405=E6=9C=8824=E6=97=A5 16:26, Michael S. Tsirkin wrote: > >On Tue, May 24, 2016 at 04:03:04PM +0800, Jason Wang wrote: > >>> > >>> > >>>On 2016=E5=B9=B405=E6=9C=8824=E6=97=A5 04:14,wexu@redhat.com wrote: > >>>> >From: Wei Xu > >>>> > > >>>> >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 ne= ed to be > >>>> >discussed with windows driver maintainer, so linux guests with th= is patch > >>>> >won't work at current, haven't figure it out yet, but i'm guessin= g 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 an= d > >>>> >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 involv= ement in > >>>this series. In this way, the issues were limited and can be converg= ed 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. > > >=20 > 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. --=20 MST