From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZH9fm-0005kg-6c for qemu-devel@nongnu.org; Mon, 20 Jul 2015 07:55:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZH9fi-0005Ps-5R for qemu-devel@nongnu.org; Mon, 20 Jul 2015 07:55:54 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:61686) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZH9ff-0005Os-SW for qemu-devel@nongnu.org; Mon, 20 Jul 2015 07:55:50 -0400 References: <55AC9859.3050100@cn.fujitsu.com> <20150720103208.GA12675@stefanha-thinkpad.redhat.com> From: zhanghailiang Message-ID: <55ACE1B4.4010109@huawei.com> Date: Mon, 20 Jul 2015 19:55:32 +0800 MIME-Version: 1.0 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 , Li Zhijian Cc: qemu-devel@nongnu.org, jan.kiszka@siemens.com, jasowang@redhat.com, dgilbert@redhat.com, peter.huangpeng@huawei.com, "Gonglei (Arei)" , stefanha@redhat.com, Yang Hongyang On 2015/7/20 18:32, 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? > Yes, but we decided to re-implement it in userspace (Here is in qemu), there are mainly two reasons that we made this change. One is the colo-proxy in kernel is narrowly used, which can only be used for COLO FT, besides, we have to modify iptables and nftables to support this capability. IMHO, it is hardly been accepted by the kernel community. The other reason is that the kernel proxy scenario can't been used in all situations, for example, evs + vhost-user + dpdk, it can't work if VM's network packets don't go through host's network stack. (For the new userspace colo proxy scheme, we also can't use it with vhost-net, we have to use virtio-net instead). > 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. > > 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? > > Does the proxy need to perform privileged operations, create sockets, > open files, etc? > > 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. > Agreed, besides, it is seemed that slirp is not supporting ipv6, we also have to supplement it. Thanks, zhanghailiang