From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39237) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aY8RF-0008Ie-8X for qemu-devel@nongnu.org; Tue, 23 Feb 2016 03:35:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aY8RC-0004hs-08 for qemu-devel@nongnu.org; Tue, 23 Feb 2016 03:35:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41350) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aY8RB-0004hd-QF for qemu-devel@nongnu.org; Tue, 23 Feb 2016 03:35:17 -0500 References: <1454750932-7556-1-git-send-email-zhang.zhanghailiang@huawei.com> <1454750932-7556-32-git-send-email-zhang.zhanghailiang@huawei.com> <56C533D3.5020307@redhat.com> <56C53A22.2010706@huawei.com> From: Jason Wang Message-ID: <56CC19AE.3010200@redhat.com> Date: Tue, 23 Feb 2016 16:34:54 +0800 MIME-Version: 1.0 In-Reply-To: <56C53A22.2010706@huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH COLO-Frame v14 31/40] net/filter: Add a 'status' property for filter object List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hailiang Zhang , qemu-devel@nongnu.org Cc: xiecl.fnst@cn.fujitsu.com, lizhijian@cn.fujitsu.com, quintela@redhat.com, armbru@redhat.com, yunhong.jiang@intel.com, eddie.dong@intel.com, peter.huangpeng@huawei.com, dgilbert@redhat.com, arei.gonglei@huawei.com, stefanha@redhat.com, amit.shah@redhat.com, zhangchen.fnst@cn.fujitsu.com, hongyang.yang@easystack.cn On 02/18/2016 11:27 AM, Hailiang Zhang wrote: >>> +static void netfilter_set_status(Object *obj, const char *str, >>> Error **errp) >>> +{ >>> + NetFilterState *nf = NETFILTER(obj); >>> + >>> + if (!strcmp(str, "enable")) { >>> + nf->enabled = true; >>> + } else if (!strcmp(str, "disable")) { >>> + nf->enabled = false; >> >> Do we need a filter specific callback here to drain filter's queue? E.g >> for filter-buffer ,need to release all the packets that has been >> buffered. >> > > I don't think we need to do that here, we drain the filter's queue > explicitly > when we try to change the filter's status . I think we don't do this. E.g what happens if we disable a filter buffer? > Besides, it seems that, we didn't have a callback in filter layer to > process > the queued packets for different types of filters. Just need a type specific callback, no?