From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMZ4s-0006ha-Bd for qemu-devel@nongnu.org; Fri, 22 Jan 2016 05:36:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMZ4m-0000cc-5a for qemu-devel@nongnu.org; Fri, 22 Jan 2016 05:36:26 -0500 Received: from szxga02-in.huawei.com ([119.145.14.65]:42913) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMZ4l-0000cN-Cp for qemu-devel@nongnu.org; Fri, 22 Jan 2016 05:36:20 -0500 References: <1453451811-11860-1-git-send-email-zhang.zhanghailiang@huawei.com> <20160122100756.GD14825@redhat.com> From: Hailiang Zhang Message-ID: <56A20604.4000407@huawei.com> Date: Fri, 22 Jan 2016 18:35:48 +0800 MIME-Version: 1.0 In-Reply-To: <20160122100756.GD14825@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 0/7] Netfilter: Add each netdev a default filter List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: jasowang@redhat.com, hongyang.yang@easystack.cn, peter.huangpeng@huawei.com, zhangchen.fnst@cn.fujitsu.com, qemu-devel@nongnu.org On 2016/1/22 18:07, Daniel P. Berrange wrote: > On Fri, Jan 22, 2016 at 04:36:44PM +0800, zhanghailiang wrote: >> This series is a prerequisite for COLO, here we add each netdev >> a default buffer filter, it is disabled by default, and has >> no side effect for delivering packets in net layer. > > Why can't whatever is launching QEMU just setup filters explicitly > if they want to use COLO ? I'm not seeing an obvious compelling > reason to add this by default and then add extra code to deal > with special casing its behaviour. > The main reason is, we hope to support hot add network during VM's COLO lifetime in the future. (I'm not quite sure if this usage case is really exist, but we don't want the VM in COLO state has too many limitations.) Maybe add an option that users can control if they want to use COLO or not is more acceptable ? With this option, we can decide whether to add the default filter or not. Or, we could dynamically add filter while users ask to go into COLO state for VM. (We have discussed this before in community, and Jason suggested me to add default filter for each netdev to support hot-add network during COLO state). What's your suggestion ? Thanks, Hailiang >> >> Besides, patch 1 fixes the ouput information of 'info network' command >> for filter. >> >> zhanghailiang (7): >> net/filter: Fix the output information for command 'info network' >> net/filter: Add a 'status' property for filter object >> net/filter: Skip the disabled filter when delivering packets >> net/filter: Introduce a helper to add a filter to the netdev >> filter-buffer: Accept zero interval >> net/filter: Add a default filter to each netdev >> net/filter: prevent the default filter to be deleted >> >> include/net/filter.h | 25 +++++++- >> net/dump.c | 2 - >> net/filter-buffer.c | 10 ---- >> net/filter.c | 163 +++++++++++++++++++++++++++++++++++++++++++++------ >> net/net.c | 27 ++++++++- >> 5 files changed, 194 insertions(+), 33 deletions(-) > > Regards, > Daniel >