From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0lZ7-00054S-Hg for qemu-devel@nongnu.org; Thu, 12 May 2016 04:01:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0lZ0-00071d-9V for qemu-devel@nongnu.org; Thu, 12 May 2016 04:01:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40754) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0lZ0-00071Z-0g for qemu-devel@nongnu.org; Thu, 12 May 2016 04:01:42 -0400 References: <1460977906-25218-1-git-send-email-zhangchen.fnst@cn.fujitsu.com> <1460977906-25218-2-git-send-email-zhangchen.fnst@cn.fujitsu.com> <5721B379.5080809@redhat.com> <5721B8D0.3030700@redhat.com> <5721C1E8.4040409@cn.fujitsu.com> <5721C6FE.6050301@redhat.com> <5721D21C.6070202@cn.fujitsu.com> <5722C0D6.8080805@redhat.com> <572C2EB4.1090005@cn.fujitsu.com> <572C3BAF.5080106@redhat.com> <57306B3C.5090000@cn.fujitsu.com> <5734275C.8070406@cn.fujitsu.com> From: Jason Wang Message-ID: <5734385B.6040004@redhat.com> Date: Thu, 12 May 2016 16:01:31 +0800 MIME-Version: 1.0 In-Reply-To: <5734275C.8070406@cn.fujitsu.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH V3 1/4] colo-compare: introduce colo compare initlization List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhang Chen , qemu devel Cc: zhanghailiang , Li Zhijian , Gui jianfeng , "eddie.dong" , "Dr. David Alan Gilbert" , Yang Hongyang On 2016=E5=B9=B405=E6=9C=8812=E6=97=A5 14:49, Zhang Chen wrote: > > > On 05/09/2016 06:49 PM, Zhang Chen wrote: >> >>> + >>> + s->chr_sec_in =3D qemu_chr_find(s->sec_indev); >>> + if (s->chr_sec_in =3D=3D NULL) { >>> + error_setg(errp, "Secondary IN Device '%s' not found", >>> + s->sec_indev); >>> + return; >>> + } >>> + >>> + s->chr_out =3D qemu_chr_find(s->outdev); >>> + if (s->chr_out =3D=3D NULL) { >>> + error_setg(errp, "OUT Device '%s' not found", s->outdev); >>> + return; >>> + } >>> + >>> + qemu_chr_fe_claim_no_fail(s->chr_pri_in); >>> + qemu_chr_add_handlers(s->chr_pri_in, compare_chr_can_read, >>> + compare_pri_chr_in, NULL, s); >>> + >>> + qemu_chr_fe_claim_no_fail(s->chr_sec_in); >>> + qemu_chr_add_handlers(s->chr_sec_in, compare_chr_can_read, >>> + compare_sec_chr_in, NULL, s); >>> + >>>>>>>>> Btw, what's the reason of handling this in main loop? I=20 >>>>>>>>> thought it >>>>>>>>> would >>>>>>>>> be better to do this in colo thread? Otherwise, you need lots o= f >>>>>>>>> extra >>>>>>>>> synchronizations? >>>>>>>> Do you mean we should start/stop/do checkpoint it by colo-frame? >>>>>>> I mean we probably want to handle pri_in and sec_in in colo compa= re >>>>>>> thread. Through this way, there's no need for extra synchronizati= on >>>>>>> with >>>>>>> main loop. >>>>>> I get your point, but how to do this. >>>>>> Now, we use qemu_chr_add_handlers to do this job. >>>>> You probably want to start a new main loop in colo comparing thread= . >>>> >>>> IIUC, do you mean >>>> - remove char device read_handler >>>> >>>> =E2=86=93at colo comparing thread=E2=86=93 >>>> while (true) { >>>> - blocking read packet from char device with select(2)/poll(2)... >>>> - compare packet >>>> } >>> Yes, something like this. >>> >> >> But remove qemu_chr_add_handlers I can't get fd to select/poll. >> >> How to get fd from all kinds of chardev? >> > > Hi~ jason. > > If we use chardev socket the fd save in QIOChannelSocket. > > and if we use chardev file the fd save in QIOChannelFile. > > Have any common method to get fd? I'm not sure I get the question. But you probably can call=20 qemu_chr_add_handlers() in colo comparing thread to solve this I think? > >> Thanks >> Zhang Chen >> >>>> This solution will lead comparing packet and reading packet in seria= l. >>>> But i don't know if this will have a good performance. >>> This probably won't have the best performance but it simplify lots of >>> things. Actually doing it in main loop will slow down all other I/O >>> processing. Consider colo can only handling userspace network traffic >>> now, we could start from this. For performance, it needs lots of othe= r >>> stuff: I think the most important thing is to add vhost support. >>> >>> Thanks >>> >>>>>> Thanks >>>>>> zhangchen >>>>> >>>>> . >>>>> >>> >>> >>> . >>> >> >