From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQAxL-0007eO-I2 for qemu-devel@nongnu.org; Mon, 01 Feb 2016 04:39:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQAxI-0000NX-BZ for qemu-devel@nongnu.org; Mon, 01 Feb 2016 04:39:35 -0500 Received: from szxga03-in.huawei.com ([119.145.14.66]:19387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQAxH-0000ND-Ow for qemu-devel@nongnu.org; Mon, 01 Feb 2016 04:39:32 -0500 References: <1453883380-10532-1-git-send-email-zhang.zhanghailiang@huawei.com> <1453883380-10532-4-git-send-email-zhang.zhanghailiang@huawei.com> <56AECDA8.6000402@redhat.com> <56AEF788.3080706@huawei.com> <56AF0D63.3010707@redhat.com> <56AF0FC4.7070809@huawei.com> <56AF11DA.1060208@easystack.cn> <56AF158F.7090208@huawei.com> <56AF22D6.5040904@redhat.com> From: Hailiang Zhang Message-ID: <56AF27B7.5060508@huawei.com> Date: Mon, 1 Feb 2016 17:39:03 +0800 MIME-Version: 1.0 In-Reply-To: <56AF22D6.5040904@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC v2 3/5] net/filter: Introduce a helper to add a filter to the netdev List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang , Yang Hongyang , qemu-devel@nongnu.org Cc: peter.huangpeng@huawei.com, zhangchen.fnst@cn.fujitsu.com On 2016/2/1 17:18, Jason Wang wrote: > > > On 02/01/2016 04:21 PM, Hailiang Zhang wrote: >>>>>>> >>>>>>> Instead of this, I wonder maybe it's better to: >>>>>>> >>>>>>> - store the default filter property into a pointer to string >>>>>> >>>>>> Do you mean, pass a string parameter which stores the filter property >>>>>> instead of >>>>>> assemble it in this helper ? >>>>> >>>>> Yes. E.g just a global string which could be changed by any subsystem. >>>>> E.g colo may change it to >>>>> "filter-buffer,interval=0,status=disable". But >>>>> filter ids need to be generated automatically. >>>>> >>>> >>>> Got it. Then we don't need the global default_netfilter_type[] in >>>> patch 5, >>>> Just use this global string instead ? >>>> >>>>>> >>>>>>> - colo code may change the pointer to "filter-buffer,status=disable" >>>>>>> >>>>>> >>>>>>> Then, there's no need for lots of codes above: >>>>>>> - no need a "is_default" parameter in netdev_add_filter which >>>>>>> does not >>>>>>> scale consider we may want to have more property in the future >>>>>>> - no need to hacking like "qemu_filter_opts" >>>>>> >>>>>> Yes, we can use qemu_find_opts("object") instead of it. >>>>>> >>>>>>> - no need to have a special flag like "is_default" >>>>>>> >>>>>> >>>>>> But we have to distinguish the default filter from the common >>>>>> filter, use the name (id) to distinguish it ? >>>>> >>>>> What's the reason that you want to distinguish default filters from >>>>> others? >>>>> >>>> >>>> The default filters will be used by COLO or MC, (In COLO, we will >>>> use it >>>> to control packets buffering/releasing). >>>> For COLO, we don't want to control (use) other filters that added by >>>> users. >>> >>> I think Jason's point is that COLO is a manager, you can add the filter >>> to netdev when doing COLO, so the only difference between COLO's default >> >> Er, then we came back to the original question, 'is it necessary to >> add each netdev >> a default filter ?' > > The question could be extended to: > > 1) Do we need a default filter? I think the answer is yes, but of course > COLO can work even without this. Yes, after colo-proxy is realized, we can switch to colo-proxy (It should have the capability of buffer and release packets directly). But for now, we want to merge COLO prototype without colo-proxy, the COLO prototype should have the basic capability. Just like Remus or Micro-checkpointing. It is based on the default buffer-filter to control net packets. > 2) Do we want to implement COLO on top of default filter? If yes, as you > suggest, we may record the ids of the default filter and do what ever we Yes, we need it. > what. If not, COLO need codes to go through each netdev and add filter > itself (hotplug is not supported). Or you want management to do this, > then even hotplug could be supported. > We also want to support hotplug during VM is in COLO state in the future. (For this point, I'm not quite sure if this usage case is really exist.) Thanks, Hailiang > Any thoughts? > >> If we add the a filter to netdev when doing COLO, it will be added >> dynamically, >> Here we want to add each netdev a default filter while launch QEMU >> (no matter if this VM will go into COLO or not), >> just to support hot-add NIC for VM while in COLO lifetime. > > Yes. > > > > > . >