From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cqFsw-0004oI-UN for qemu-devel@nongnu.org; Tue, 21 Mar 2017 05:15:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cqFst-0003Ci-Qo for qemu-devel@nongnu.org; Tue, 21 Mar 2017 05:15:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37396) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cqFst-0003Bq-In for qemu-devel@nongnu.org; Tue, 21 Mar 2017 05:15:19 -0400 References: <1489657928-14919-1-git-send-email-zhangchen.fnst@cn.fujitsu.com> <22303218-697c-7166-406b-050888efdfd5@redhat.com> <8901e058-dcda-5c4a-e43a-38fca5814eb5@redhat.com> <2875d736-61ae-b8f6-bb79-40aaddf3cb9b@redhat.com> From: Jason Wang Message-ID: <15aa7299-d364-cb03-f07f-778dfbb1f8a4@redhat.com> Date: Tue, 21 Mar 2017 17:15:10 +0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/3] Add COLO-proxy virtio-net support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhang Chen , qemu devel Cc: Li Zhijian , "eddie . dong" , bian naimeng , zhanghailiang On 2017=E5=B9=B403=E6=9C=8821=E6=97=A5 15:08, Zhang Chen wrote: > > > On 03/21/2017 02:30 PM, Jason Wang wrote: >> >> >> On 2017=E5=B9=B403=E6=9C=8821=E6=97=A5 14:16, Zhang Chen wrote: >>> >>> >>> On 03/21/2017 02:10 PM, Jason Wang wrote: >>>> >>>> >>>> On 2017=E5=B9=B403=E6=9C=8821=E6=97=A5 13:47, Zhang Chen wrote: >>>>> >>>>> >>>>> On 03/21/2017 11:39 AM, Jason Wang wrote: >>>>>> >>>>>> >>>>>> On 2017=E5=B9=B403=E6=9C=8816=E6=97=A5 17:52, Zhang Chen wrote: >>>>>>> If user use -device virtio-net-pci, virtio-net driver will add a=20 >>>>>>> header >>>>>>> to raw net packet that colo-proxy can't handle it. COLO-proxy jus= t >>>>>>> focus on the packet payload, so we skip the virtio-net header to=20 >>>>>>> compare >>>>>>> the sent packet that primary guest's to secondary guest's. >>>>>>> >>>>>>> >>>>>>> Zhang Chen (3): >>>>>>> COLO-proxy: Add virtio-net packet parse function >>>>>>> COLO-proxy: Add a tag to mark virtio-net packet >>>>>>> COLO-compare: Add virtio-net packet compare support >>>>>>> >>>>>>> net/colo-compare.c | 42=20 >>>>>>> +++++++++++++++++++++++++++++++++--------- >>>>>>> net/colo.c | 14 ++++++++++---- >>>>>>> net/colo.h | 7 ++++++- >>>>>>> net/filter-rewriter.c | 15 ++++++++++----- >>>>>>> 4 files changed, 59 insertions(+), 19 deletions(-) >>>>>>> >>>>>> >>>>>> Hi: >>>>>> >>>>>> Git grep told us virtio-net is not the only user for vnet header.=20 >>>>>> E1000e and vmxnet3 uses it too. >>>>>> >>>>>> So we need solve them all instead of being virtio-net specific. >>>>>> >>>>> >>>>> Yes, In this series I just try to parse vnet header, if failed I=20 >>>>> will try to parse normal net packet. >>>>> So, I just focus on vnet header rather than virtio-net driver. >>>>> But the patch comments really make people confused , Should I fix=20 >>>>> all the comments send the V2 ? >>>> >>>> Yes, please. Beside this, instead of using fixed vnet header len=20 >>>> macro, you should query the backend for the length of vnet header. >>> >>> I want query the backend too, but colo-compare is not a netfilter=20 >>> means it no need attach any netdev. >>> How can we query the backend for the length of vnet header? >> >> Filters can know this, then how about let filters add the vnet header=20 >> length before the real packet and send it to colo-compare? >> > > I don't know whether I understand your comments... > Do you means filter send a vnet header length firstly(independent=20 > length packet), then send the real packet? This requires too much changes and may break the compatibility of socket=20 net backend. > If yes, I think it so expensive, in colo we use filter mirror or=20 > redirect packet between primary and secondary > that no need to know the vnet header length. > Or do you means add a fake vnet header to real packet in same one packe= t? Kind of, see below. > If yes, filter-mirror and filter-redirector must touch the packet do=20 > some job like colo-compare. > We initial design split colo-proxy to 4 modules have make=20 > filter-mirror and filter-redirector not to touch > the packet content, colo-compare and filter-rewriter do the packet=20 > data related job. > Or you have other way to tell colo-compare the length? > > Thanks > Zhang Chen I mean e.g: We send a packet like struct {int size; const uint8_t=20 buf[];} currently. We can try to add vnet header information like {int=20 size; int vnet_hdr_len; const uint8_t buf[];}. Or even just pack the=20 vnet_hdr_len information to the higher bits of size. Then we just need=20 some encoding and decoding and the changes were limited. Does this make sense? Thanks