From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCqLf-0003fF-MW for qemu-devel@nongnu.org; Wed, 08 Jul 2015 10:29:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZCqLb-0002Td-G7 for qemu-devel@nongnu.org; Wed, 08 Jul 2015 10:29:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCqLb-0002TQ-Bj for qemu-devel@nongnu.org; Wed, 08 Jul 2015 10:29:15 -0400 Date: Wed, 8 Jul 2015 17:29:11 +0300 From: "Michael S. Tsirkin" Message-ID: <20150708171653-mutt-send-email-mst@redhat.com> References: <1432776186-24515-1-git-send-email-changchun.ouyang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432776186-24515-1-git-send-email-changchun.ouyang@intel.com> Subject: Re: [Qemu-devel] [PATCH v5] vhost-user: add multi queue support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ouyang Changchun Cc: snabb-devel@googlegroups.com, Marcel Apfelbaum , qemu-devel@nongnu.org, n.nikolaev@virtualopensystems.com, luke@snabb.co, thomas.long@intel.com, rkhan@redhat.com On Thu, May 28, 2015 at 09:23:06AM +0800, Ouyang Changchun wrote: > Based on patch by Nikolay Nikolaev: > Vhost-user will implement the multi queue support in a similar way > to what vhost already has - a separate thread for each queue. > To enable the multi queue functionality - a new command line parameter > "queues" is introduced for the vhost-user netdev. > > Signed-off-by: Nikolay Nikolaev > Signed-off-by: Changchun Ouyang So testing turned up a significant issue with the protocol extension in this one. Specifically, remote has no idea how many queues guest actually wants to use (it's dynamic, guest changes this at any time). We need support for enabling and disabling queues dynamically. Given we are past hard freeze, and given no one uses this yet (dpdk upstream did not merge supporting protocol), I think the best thing to do is to disable this functionality for 2.4. I will send a patch to do this shortly. I do think this support is important, so me and Marcel will try work on it in the coming several weeks, and to come up with a better protocol. I hope we'll be able to have a replacement ready by the time 2.4 is released and 2.5 development opens up so it can be merged first thing. It also seems that it will also align better with the plans to use this in upstream dpdk. -- MST