From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58186) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0lnV-0004Ro-D6 for qemu-devel@nongnu.org; Thu, 12 May 2016 04:16:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0lnQ-00016O-8L for qemu-devel@nongnu.org; Thu, 12 May 2016 04:16:41 -0400 Received: from [59.151.112.132] (port=43344 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0lnO-0000v8-Ry for qemu-devel@nongnu.org; Thu, 12 May 2016 04:16:36 -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> <5734385B.6040004@redhat.com> From: Zhang Chen Message-ID: <57343BD0.5060206@cn.fujitsu.com> Date: Thu, 12 May 2016 16:16:16 +0800 MIME-Version: 1.0 In-Reply-To: <5734385B.6040004@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit 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: Jason Wang , qemu devel Cc: zhanghailiang , Li Zhijian , Gui jianfeng , "eddie.dong" , "Dr. David Alan Gilbert" , Yang Hongyang On 05/12/2016 04:01 PM, Jason Wang wrote: > > > On 2016年05月12日 14:49, Zhang Chen wrote: >> >> >> On 05/09/2016 06:49 PM, Zhang Chen wrote: >>> >>>> + >>>> + s->chr_sec_in = qemu_chr_find(s->sec_indev); >>>> + if (s->chr_sec_in == NULL) { >>>> + error_setg(errp, "Secondary IN Device '%s' not found", >>>> + s->sec_indev); >>>> + return; >>>> + } >>>> + >>>> + s->chr_out = qemu_chr_find(s->outdev); >>>> + if (s->chr_out == 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 >>>>>>>>>> thought it >>>>>>>>>> would >>>>>>>>>> be better to do this in colo thread? Otherwise, you need lots of >>>>>>>>>> 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 >>>>>>>> compare >>>>>>>> thread. Through this way, there's no need for extra >>>>>>>> synchronization >>>>>>>> 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 >>>>> >>>>> ↓at colo comparing thread↓ >>>>> 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 > qemu_chr_add_handlers() in colo comparing thread to solve this I think? > I have tested call qemu_chr_add_handlers() in colo comparing thread, but when data come, the handler always running in main loop. Thanks Zhang Chen >> >>> Thanks >>> Zhang Chen >>> >>>>> This solution will lead comparing packet and reading packet in >>>>> serial. >>>>> 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 other >>>> stuff: I think the most important thing is to add vhost support. >>>> >>>> Thanks >>>> >>>>>>> Thanks >>>>>>> zhangchen >>>>>> >>>>>> . >>>>>> >>>> >>>> >>>> . >>>> >>> >> > > > > . > -- Thanks zhangchen