From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZH9me-0008Oh-Vs for qemu-devel@nongnu.org; Mon, 20 Jul 2015 08:03:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZH9ma-0000da-Gc for qemu-devel@nongnu.org; Mon, 20 Jul 2015 08:03:00 -0400 Received: from [59.151.112.132] (port=11462 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZH9ma-0000ce-4D for qemu-devel@nongnu.org; Mon, 20 Jul 2015 08:02:56 -0400 Message-ID: <55ACE36A.7010903@cn.fujitsu.com> Date: Mon, 20 Jul 2015 20:02:50 +0800 From: Li Zhijian MIME-Version: 1.0 References: <55AC9859.3050100@cn.fujitsu.com> <20150720103208.GA12675@stefanha-thinkpad.redhat.com> In-Reply-To: <20150720103208.GA12675@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed 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: Stefan Hajnoczi Cc: zhanghailiang , jan.kiszka@siemens.com, jasowang@redhat.com, "peter.huangpeng" , qemu-devel@nongnu.org, "Gonglei (Arei)" , stefanha@redhat.com, Yang Hongyang , dgilbert@redhat.com CC Wen Congyang On 07/20/2015 06:32 PM, Stefan Hajnoczi wrote: > 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? > > Why does the proxy need to be part of the QEMU process? -netdev socket > or host network stack features allow you to process packets in a > separate process. yes, it used to be a kernel module. we plan to re-implement a QEMU space colo-proxy by the following reasons: 1. colo-proxy in kernel was based on netfilter, it was impletmented by add a new nf_ct_ext_id, but this will touch the existed kernel code and we must re-build the kernel before we install the colo-proxy modules. For this reason, less people is like to test colo-proxy and it become harder to post to kenel 2. COLO is the only scene of colo-proxy in kernel 3. colo-proxy in kernel only works on the case where packet will deliver to kernel tcp/ip stack. COLO project is mainly including 3 components, COLO-Frame COLO-Block and COLO-Proxy. The first tow components is being post to QEMU, if we integrate proxy into QEMU, it will become convenienter to manage the whole COLO project. further more, COLO will become easier to configure without depending on kernel > Without details on what the proxy does it's hard to discuss this. What > happens in the non-TCP case? What happens in the TCP case? more details will be post soon > Does the proxy need to perform privileged operations, create sockets, > open files, etc? IMO, we just need to create a new socket like the migration socket to forward packet between PVM and SVM. Best regards. Li Zhijian > The slirp code is not actively developed or used much in production. It > might be a good idea to audit the code for bugs if you want to use it. > > Stefan