From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8kiY-0004rR-MN for qemu-devel@nongnu.org; Tue, 15 Dec 2015 03:12:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8kiV-0006zH-HJ for qemu-devel@nongnu.org; Tue, 15 Dec 2015 03:12:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8kiV-0006wA-Cz for qemu-devel@nongnu.org; Tue, 15 Dec 2015 03:12:15 -0500 References: <1449921644-31673-1-git-send-email-shmulik.ladkani@ravellosystems.com> <1449921644-31673-6-git-send-email-shmulik.ladkani@ravellosystems.com> <566E60A4.7070603@redhat.com> <20151214093249.33cf4e6c@pixies> <566F7C8F.6010701@redhat.com> <20151215080954.725b03df@halley> From: Jason Wang Message-ID: <566FCB57.3090902@redhat.com> Date: Tue, 15 Dec 2015 16:12:07 +0800 MIME-Version: 1.0 In-Reply-To: <20151215080954.725b03df@halley> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 5/7] vmxnet3: The vmxnet3 device is a PCIE endpoint List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Shmulik Ladkani Cc: Dmitry Fleytman , Marcel Apfelbaum , idan.brown@ravellosystems.com, qemu-devel@nongnu.org On 12/15/2015 02:09 PM, Shmulik Ladkani wrote: > Hi Jason, > > On Tue, 15 Dec 2015 10:35:59 +0800 Jason Wang wrote: >>> Another attempt I've made is to indroduce a new type vmxnet3e (the >>> pcie variant of vmxnet3). >>> I dropped this approach since it was way too cumbersome, introducing >>> lots of boiler-plate code for the two (otherwise) identical types. >> Yes, that's another solution (as I replied for patch 6). A question >> here. If vmware differs pci-e version of vmxnet3 from pci version, >> probably we need do the same (and you don't even need to care for >> compatibility in the case). At a quick glance, no much duplicated codes. >> (if you mean the msi offsets, you can let vmxnet3e use the new offset >> unconditionally). > Examples of duplicated boiler plate: > > Split to a TYPE_VMXNET3_BASE abstract type having two concrete sub types. > > Introduction of 'VMStateDescription vmstate_vmxnet3e' which differs only > due to its '.name' (must be the name of the type, i.e "vmxnet3e") and > the use of VMSTATE_PCIE_DEVICE (instead of VMSTATE_PCI_DEVICE), but > otherwise idential to existing 'VMStateDescription vmstate_vmxnet3'. > > Introduction of 'VMStateDescription vmxstate_vmxnet3e_mcast_list' which > differs only by '.name' (must be "vmxnet3e/mcast_list" instead of > "vmxnet3/mcast_list") but otherwise identical to existing > 'vmxstate_vmxnet3_mcast_list'. > > Also, the vmxnet3 device is indeed a PCIE, and should have been so since > start. Yes, so this is a strong reason that we must not introduce a new type. > The reason we're keeping the non-pcie variant is not since user would be > interested in an environment having the the non-pcie type, but only for > not breaking migration from old hardware versions. > > Thus, suggesting 2 device types, providing the non-pcie variant as a > user visible type, exposes the user with a choice of selecting a type > which ideally shouldn't have existed at all. > This seems less preferrable. > > Regards, > Shmulik > I get the point, thanks for the clarification.