From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49676) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJdE5-0004Ib-Un for qemu-devel@nongnu.org; Mon, 27 Jul 2015 03:53:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJdE3-000490-8e for qemu-devel@nongnu.org; Mon, 27 Jul 2015 03:53:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJdE3-00048w-0i for qemu-devel@nongnu.org; Mon, 27 Jul 2015 03:53:31 -0400 Message-ID: <55B5E375.30600@redhat.com> Date: Mon, 27 Jul 2015 15:53:25 +0800 From: Jason Wang MIME-Version: 1.0 References: <55AC9859.3050100@cn.fujitsu.com> <20150720103208.GA12675@stefanha-thinkpad.redhat.com> <55B19F25.10905@redhat.com> <55B1F196.2000008@cn.fujitsu.com> <55B5A465.6030004@redhat.com> <55B5AB70.3030704@cn.fujitsu.com> <55B5B85B.1010009@redhat.com> <55B5C6E9.6090707@cn.fujitsu.com> In-Reply-To: <55B5C6E9.6090707@cn.fujitsu.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [POC] colo-proxy in qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yang Hongyang , "Dong, Eddie" , Stefan Hajnoczi , Li Zhijian Cc: zhanghailiang , "jan.kiszka@siemens.com" , "qemu-devel@nongnu.org" , "peter.huangpeng" , "Gonglei (Arei)" , "stefanha@redhat.com" , "dgilbert@redhat.com" On 07/27/2015 01:51 PM, Yang Hongyang wrote: > On 07/27/2015 12:49 PM, Jason Wang wrote: >> >> >> On 07/27/2015 11:54 AM, Yang Hongyang wrote: >>> >>> >>> On 07/27/2015 11:24 AM, Jason Wang wrote: >>>> >>>> >>>> On 07/24/2015 04:04 PM, Yang Hongyang wrote: >>>>> Hi Jason, >>>>> >>>>> On 07/24/2015 10:12 AM, Jason Wang wrote: >>>>>> >>>>>> >>>>>> On 07/24/2015 10:04 AM, Dong, Eddie wrote: >>>>>>> Hi Stefan: >>>>>>> Thanks for your comments! >>>>>>> >>>>>>>> On Mon, Jul 20, 2015 at 02:42:33PM +0800, Li Zhijian wrote: >>>>>>>>> We are planning to implement colo-proxy in qemu to cache and >>>>>>>>> compare >>>>>>>> packets. >>>>>>>> >>>>>>>> I thought there is a kernel module to do that? >>>>>>> Yes, that is the previous solution the COLO sub-community >>>>>>> choose >>>>>>> to go, but we realized it might be not the best choices, and >>>>>>> thus we >>>>>>> want to bring discussion back here :) More comments are welcome. >>>>>>> >>>>>> >>>>>> Hi: >>>>>> >>>>>> Could you pls describe more details on this decision? What's the >>>>>> reason >>>>>> that you realize it was not the best choice? >>>>> >>>>> Below is my opinion: >>>>> >>>>> We realized that there're disadvantages do it in kernel spaces: >>>>> 1. We need to recompile kernel: the colo-proxy kernel module is >>>>> implemented as a nf conntrack extension. Adding a extension >>>>> need to >>>>> modify the extension struct in-kernel, so recompile kernel is >>>>> needed. >>>> >>>> There's no need to do all in kernel, you can use a separate process to >>>> do the comparing and trigger the state sync through monitor. >>> >>> I don't get it, colo-proxy kernel module using a kthread do the >>> comparing and >>> trigger the state sync. We implemented it as a nf conntrack extension >>> module, >>> so we need to extend the extension struct in-kernel, although it just >>> needs >>> few lines changes to kernel, but a recompile of kernel is needed. >>> Are you >>> talking about not implement it as a nf conntrack extension? >> >> Yes, I mean implement the comparing in userspace but not in qemu. > > Yes, it is an alternative, that requires other components such as > netfilter userspace tools, it will add the complexity I think, we > wanted to implement a simple solution in QEMU. I didn't get the point that why netfilter is needed? Do you mean the packet comparing needs to be stateful? > Another reason is > that using other userspace tools will affect the performance, the > context switch between kernel and userspace may be an overhead. We can use 100% time of this process but looks like your RFC of filter just did it in iothread?