From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeKGZ-0001Tg-8U for qemu-devel@nongnu.org; Tue, 22 Sep 2015 05:53:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZeKGW-0006Cv-1d for qemu-devel@nongnu.org; Tue, 22 Sep 2015 05:53:39 -0400 Received: from [59.151.112.132] (port=61524 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeKGV-0006BD-CU for qemu-devel@nongnu.org; Tue, 22 Sep 2015 05:53:35 -0400 Message-ID: <560123AB.6070600@cn.fujitsu.com> Date: Tue, 22 Sep 2015 17:47:23 +0800 From: Yang Hongyang MIME-Version: 1.0 References: <1442405768-23019-1-git-send-email-yanghy@cn.fujitsu.com> <1442405768-23019-13-git-send-email-yanghy@cn.fujitsu.com> <56010511.2040303@redhat.com> <56010C59.1040903@cn.fujitsu.com> <56011234.4040306@redhat.com> <560114B0.5090208@cn.fujitsu.com> <56011FB1.1060707@redhat.com> In-Reply-To: <56011FB1.1060707@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v11 12/12] netfilter: add multiqueue support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang , qemu-devel@nongnu.org Cc: thuth@redhat.com, zhang.zhanghailiang@huawei.com, lizhijian@cn.fujitsu.com, armbru@redhat.com, Yang Hongyang , stefanha@redhat.com On 09/22/2015 05:30 PM, Jason Wang wrote: [...] >>>>>> >>>>>> if (!nf->netdev_id) { >>>>>> error_setg(errp, "Parameter 'netdev' is required"); >>>>>> @@ -165,9 +174,6 @@ static void netfilter_complete(UserCreatable >>>>>> *uc, Error **errp) >>>>>> error_setg(errp, QERR_INVALID_PARAMETER_VALUE, "netdev", >>>>>> "a network backend id"); >>>>>> return; >>>>>> - } else if (queues > 1) { >>>>>> - error_setg(errp, "Multi queue is not supported"); >>>>>> - return; >>>>>> } >>>>>> >>>>>> if (get_vhost_net(ncs[0])) { >>>>>> @@ -187,6 +193,17 @@ static void netfilter_complete(UserCreatable >>>>>> *uc, Error **errp) >>>>>> } >>>>>> QTAILQ_INSERT_TAIL(&nf->netdev->filters, nf, next); >>>>>> >>>>>> + if (queues > 1) { >>>>>> + /* >>>>>> + * Store the properties of the filter except "type" >>>>>> property. >>>>>> + * When there's multiqueue, we will create a new filter >>>>>> object >>>>>> + * of the same type and same properties. this hashtable is >>>>>> used >>>>>> + * to set newly created object properties. >>>>>> + */ >>>>>> + proptable = g_hash_table_new_full(NULL, NULL, NULL, >>>>>> + proptb_free_val_func); >>>>>> + } >>>>> >>>>> I'm thinking whether or not duplicate all the properties in each >>>>> netfilters is a good method. Maybe we can have a another ojbect with >>>>> array of pointers to NetFilter objects embedded? Another question is >>>>> whether or not we need to do this at this level. Maybe we can make the >>>>> necessary Netfilter multiqueue aware. E.g let buffer filter to have >>>>> multiqueue also? Then you may only need a single timer? >>>> >>>> Sorry I don't get it at first. I also thought about make the buffer >>>> filter to >>>> have multiqueue, but there comes problem, how to distinguish which >>>> queue >>>> we should go in when receive the packet, we need to add a mechanism to >>>> distinguish which queue belongs to which net client's queue, that will >>>> be more complex, while current multiqueue implementation of net clients >>>> is multiple net clients with the same name, current solution is the >>>> simplest >>>> solution I can think of... >>> >>> I'm not sure I get this. But there's a queue_index filed in each >>> NetClientState which may help in this case. >> >> Ah, I see, thank you. There's another reason I do this in filter abstract >> layer is that the concrete filter implementation do not need to deal >> with the >> multiqueue, will simplify the filter implement a lot, otherwise, every >> filter need to implement it's own multiqueue support. > > Probably not, just pointing all queues to a single netfilter object may > be sufficient (e.g for dump). And it's much easier for some kind of > filter (e.g traffic throttling) if it was multiqueue aware. I see, will think about doing this other way, thank you! > > . > -- Thanks, Yang.