From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id DF7835A64 for ; Tue, 27 Oct 2015 10:55:41 +0100 (CET) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 2F5C3AACE8; Tue, 27 Oct 2015 09:55:41 +0000 (UTC) Received: from redhat.com (ovpn-116-58.ams2.redhat.com [10.36.116.58]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t9R9tc5W024039; Tue, 27 Oct 2015 05:55:39 -0400 Date: Tue, 27 Oct 2015 11:55:38 +0200 From: "Michael S. Tsirkin" To: Thomas Monjalon Message-ID: <20151027115257-mutt-send-email-mst@redhat.com> References: <1445399294-18826-1-git-send-email-yuanhan.liu@linux.intel.com> <20151027093041.GI3115@yliu-dev.sh.intel.com> <20151027113807-mutt-send-email-mst@redhat.com> <1520656.Lg374xclAN@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1520656.Lg374xclAN@xps13> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: dev@dpdk.org, marcel@redhat.com Subject: Re: [dpdk-dev] [PATCH v8 3/8] vhost: vring queue setup for multiple queue support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 09:55:42 -0000 On Tue, Oct 27, 2015 at 10:51:14AM +0100, Thomas Monjalon wrote: > 2015-10-27 11:42, Michael S. Tsirkin: > > On Tue, Oct 27, 2015 at 05:30:41PM +0800, Yuanhan Liu wrote: > > > On Tue, Oct 27, 2015 at 11:17:16AM +0200, Michael S. Tsirkin wrote: > > > > Looking at that, at least when MQ is enabled, please don't key > > > > stopping queues off GET_VRING_BASE. > > > > > > Yes, that's only a workaround. I guess it has been there for quite a > > > while, maybe at the time qemu doesn't send RESET_OWNER message. > > > > RESET_OWNER was a bad idea since it basically closes > > everything. > > > > > > There are ENABLE/DISABLE messages for that. > > > > > > That's something new, > > > > That's part of multiqueue support. If you ignore them, > > nothing works properly. > > > > > though I have plan to use them instead, we still > > > need to make sure our code work with old qemu, without ENABLE/DISABLE > > > messages. > > > > OK but don't rely on this for new code. > > > > > And I will think more while enabling live migration: I should have > > > more time to address issues like this at that time. > > > > > > > Generally guys, don't take whatever QEMU happens to do for > > > > granted! Look at the protocol spec under doc/specs directory, > > > > if you are making more assumptions you must document them! > > > > > > Indeed. And we will try to address them bit by bit in future. > > > > > > --yliu > > > > But don't pile up these workarounds meanwhile. I'm very worried. The > > way you are carrying on, each new QEMU is likely to break your > > assumptions. > > I think it may be saner to increase the minimum QEMU version supported in > each DPDK release, dropping old stuff progressively. > Michael, you are welcome to suggest how to move precisely. > Thanks This doesn't work for downstreams which need to backport fixes and features. Just go by the spec, and if you find issues, fix them at the source instead of working around them - the code is open. For new features, we have protocol feature bits. -- MST