[Top][All Lists]

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

Re: [Qemu-devel] [PATCH V2 1/3] colo-compare: introduce colo compare ini

From: Li Zhijian
Subject: Re: [Qemu-devel] [PATCH V2 1/3] colo-compare: introduce colo compare initlization
Date: Fri, 1 Apr 2016 13:41:36 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 04/01/2016 01:11 PM, Jason Wang wrote:

On 03/31/2016 05:24 PM, Dr. David Alan Gilbert wrote:
* Zhang Chen (address@hidden) wrote:

On 03/30/2016 05:25 PM, Dr. David Alan Gilbert wrote:
* Zhang Chen (address@hidden) wrote:
packet come from primary char indev will be send to
outdev - packet come from secondary char dev will be drop
Please put in the description an example of how you invoke
the filter on the primary and secondary.
colo-compare get packet from chardev(primary_in,secondary_in),
and output to other chardev(outdev), so, we can use it with the
help of filter-mirror and filter-redirector. like that:
Wow, this is a bit more complicated than I expected - I was expecting just one
socket.  So let me draw this out; see comments below.

-device e1000,id=e0,netdev=hn0,mac=52:a4:00:12:78:66
-chardev socket,id=mirror0,host=,port=9003,server,nowait
-chardev socket,id=compare1,host=,port=9004,server,nowait
-chardev socket,id=compare0,host=,port=9001,server,nowait
-chardev socket,id=compare0-0,host=,port=9001
-chardev socket,id=compare_out,host=,port=9005,server,nowait
-chardev socket,id=compare_out0,host=,port=9005
-object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0
-object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out
-object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0
             ----> mirror0: socket:secondary:9003
         mirror-m0     <-- e1000
         redirector-redire1 ---> compare0 socket:primary:9001 (to compare0-0)

             -----< compare0-0 socket:primary:9001 (to compare0)
             |  primary_in
         compare-comp0       -----> compare_out0 socket:primary:9005
             |  secondary_in
             -----< compare1   socket:secondary:9004

tap <-- redirector-redire0 <--- compare_out socket:primary:9005 (from 

-netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,down
-device e1000,netdev=hn0,mac=52:a4:00:12:78:66
-chardev socket,id=red0,host=,port=9003
-chardev socket,id=red1,host=,port=9004
-object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0
-object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1
             ----> red0 socket::9003
tap <-- redirector-f1 <--
     --> redirector-f2 -->
             ----< red1 socket::9004

OK, so I think we need to find a way to fix two things:
    a) There must be an easier way of connecting two filters within the same
       qemu than going up to the kernel's socket code, around it's TCP stack
       and back.  Is there a better type of chardev to use we can short circuit
       with - it shouldn't need to leave QEMU (although I can see it's easier
       for debugging like this).  Jason/Dan - any ideas?

Looks like there's no such type of chardev. I think we could start with
tcp socket chardev first and do necessary optimization on top. In fact,
there's also advantages, with tcp sockets, the colo-compare codes could
even be an independent program out of qemu.

For the chardev type, this also reminds me one thing. Since
mirror/redirector can only work for tcp socket, we may need inspect the
chardev types and fail if not a tcp socket like what vhost-user did.

    b) We should only need one socket for the connection between primary and
       secondary - I'm not sure how to change it to let it do that.

Looks like we can (e.g for secondary):

-device e1000,netdev=hn0,mac=52:a4:00:12:78:66
-chardev socket,id=red0,host=,port=9003
-object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0
-object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red0

If not, probably a bug.

but firstly, 'chardev socket' need to enable 'mux=on' if we want two filter 
reference the
same socket.


    c) You need to be able to turn off nagling (socket no delay) on the sockets;
      I found a noticeable benefit of doing this on the connection between 
      and secondary in my world.




reply via email to

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