qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Shmulik Ladkani <shmulik.ladkani@ravellosystems.com>
Cc: Dmitry Fleytman <dmitry@daynix.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	idan.brown@ravellosystems.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v3 5/7] vmxnet3: The vmxnet3 device is a PCIE endpoint
Date: Tue, 15 Dec 2015 16:12:07 +0800	[thread overview]
Message-ID: <566FCB57.3090902@redhat.com> (raw)
In-Reply-To: <20151215080954.725b03df@halley>



On 12/15/2015 02:09 PM, Shmulik Ladkani wrote:
> Hi Jason,
>
> On Tue, 15 Dec 2015 10:35:59 +0800 Jason Wang <jasowang@redhat.com> 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.

  reply	other threads:[~2015-12-15  8:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-12 12:00 [Qemu-devel] [PATCH v3 0/7] vmxnet3: Fine-tune device capabilities Shmulik Ladkani
2015-12-12 12:00 ` [Qemu-devel] [PATCH v3 1/7] vmxnet3: Change offsets of msi/msix pci capabilities Shmulik Ladkani
2015-12-12 12:00 ` [Qemu-devel] [PATCH v3 2/7] vmxnet3: Change the offset of the MSIX PBA table Shmulik Ladkani
2015-12-12 12:00 ` [Qemu-devel] [PATCH v3 3/7] vmxnet3: Introduce 'x-old-msi-offsets' backword compatability property Shmulik Ladkani
2015-12-14  6:21   ` Jason Wang
2015-12-12 12:00 ` [Qemu-devel] [PATCH v3 4/7] vmxnet3: coding: Introduce VMXNET3Class Shmulik Ladkani
2015-12-12 12:00 ` [Qemu-devel] [PATCH v3 5/7] vmxnet3: The vmxnet3 device is a PCIE endpoint Shmulik Ladkani
2015-12-14  6:24   ` Jason Wang
2015-12-14  7:32     ` Shmulik Ladkani
2015-12-15  2:35       ` Jason Wang
2015-12-15  6:09         ` Shmulik Ladkani
2015-12-15  8:12           ` Jason Wang [this message]
2015-12-12 12:00 ` [Qemu-devel] [PATCH v3 6/7] vmxnet3: Introduce 'x-disable-pcie' backword compatability property Shmulik Ladkani
2015-12-14  6:26   ` Jason Wang
2015-12-12 12:00 ` [Qemu-devel] [PATCH v3 7/7] vmxnet3: Report the Device Serial Number capability Shmulik Ladkani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=566FCB57.3090902@redhat.com \
    --to=jasowang@redhat.com \
    --cc=dmitry@daynix.com \
    --cc=idan.brown@ravellosystems.com \
    --cc=marcel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=shmulik.ladkani@ravellosystems.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).