From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Maxime Coquelin <maxime.coquelin@redhat.com>,
dev@dpdk.org, qemu-devel@nongnu.org
Subject: Re: [PATCH 1/2] vhost: enable any layout feature
Date: Tue, 27 Sep 2016 11:11:58 +0800 [thread overview]
Message-ID: <20160927031158.GA25823@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <20160926221112-mutt-send-email-mst@kernel.org>
On Mon, Sep 26, 2016 at 10:24:55PM +0300, Michael S. Tsirkin wrote:
> On Mon, Sep 26, 2016 at 11:01:58AM -0700, Stephen Hemminger wrote:
> > I assume that if using Version 1 that the bit will be ignored
Yes, but I will just quote what you just said: what if the guest
virtio device is a legacy device? I also gave my reasons in another
email why I consistently set this flag:
- we have to return all features we support to the guest.
We don't know the guest is a modern or legacy device. That means
we should claim we support both: VERSION_1 and ANY_LAYOUT.
Assume guest is a legacy device and we just set VERSION_1 (the current
case), ANY_LAYOUT will never be negotiated.
- I'm following the way Linux kernel takes: it also set both features.
Maybe, we could unset ANY_LAYOUT when VERSION_1 is _negotiated_?
The unset after negotiation I proposed turned out it won't work: the
feature is already negotiated; unsetting it only in vhost side doesn't
change anything. Besides, it may break the migration as Michael stated
below.
> Therein lies a problem. If dpdk tweaks flags, updating it
> will break guest migration.
>
> One way is to require that users specify all flags fully when
> creating the virtio net device.
Like how? By a new command line option? And user has to type
all those features?
> QEMU could verify that all required
> flags are set, and fail init if not.
>
> This has other advantages, e.g. it adds ability to
> init device without waiting for dpdk to connect.
>
> However, enabling each new feature would now require
> management work. How about dpdk ships the list
> of supported features instead?
> Management tools could read them on source and destination
> and select features supported on both sides.
That means the management tool would somehow has a dependency on
DPDK project, which I have no objection at all. But, is that
a good idea?
BTW, I'm not quite sure I followed your idea. I mean, how it supposed
to fix the ANY_LAYOUT issue here? How this flag will be set for
legacy device?
--yliu
WARNING: multiple messages have this Message-ID (diff)
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Maxime Coquelin <maxime.coquelin@redhat.com>,
dev@dpdk.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/2] vhost: enable any layout feature
Date: Tue, 27 Sep 2016 11:11:58 +0800 [thread overview]
Message-ID: <20160927031158.GA25823@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <20160926221112-mutt-send-email-mst@kernel.org>
On Mon, Sep 26, 2016 at 10:24:55PM +0300, Michael S. Tsirkin wrote:
> On Mon, Sep 26, 2016 at 11:01:58AM -0700, Stephen Hemminger wrote:
> > I assume that if using Version 1 that the bit will be ignored
Yes, but I will just quote what you just said: what if the guest
virtio device is a legacy device? I also gave my reasons in another
email why I consistently set this flag:
- we have to return all features we support to the guest.
We don't know the guest is a modern or legacy device. That means
we should claim we support both: VERSION_1 and ANY_LAYOUT.
Assume guest is a legacy device and we just set VERSION_1 (the current
case), ANY_LAYOUT will never be negotiated.
- I'm following the way Linux kernel takes: it also set both features.
Maybe, we could unset ANY_LAYOUT when VERSION_1 is _negotiated_?
The unset after negotiation I proposed turned out it won't work: the
feature is already negotiated; unsetting it only in vhost side doesn't
change anything. Besides, it may break the migration as Michael stated
below.
> Therein lies a problem. If dpdk tweaks flags, updating it
> will break guest migration.
>
> One way is to require that users specify all flags fully when
> creating the virtio net device.
Like how? By a new command line option? And user has to type
all those features?
> QEMU could verify that all required
> flags are set, and fail init if not.
>
> This has other advantages, e.g. it adds ability to
> init device without waiting for dpdk to connect.
>
> However, enabling each new feature would now require
> management work. How about dpdk ships the list
> of supported features instead?
> Management tools could read them on source and destination
> and select features supported on both sides.
That means the management tool would somehow has a dependency on
DPDK project, which I have no objection at all. But, is that
a good idea?
BTW, I'm not quite sure I followed your idea. I mean, how it supposed
to fix the ANY_LAYOUT issue here? How this flag will be set for
legacy device?
--yliu
next prev parent reply other threads:[~2016-09-27 3:11 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-26 6:40 [PATCH 0/2] enables vhost/virtio any layout feature Yuanhan Liu
2016-09-26 6:40 ` [PATCH 1/2] vhost: enable " Yuanhan Liu
2016-09-26 18:01 ` Stephen Hemminger
2016-09-26 19:24 ` Michael S. Tsirkin
2016-09-26 19:24 ` [Qemu-devel] " Michael S. Tsirkin
2016-09-27 3:11 ` Yuanhan Liu [this message]
2016-09-27 3:11 ` Yuanhan Liu
2016-09-27 19:48 ` Stephen Hemminger
2016-09-27 19:48 ` [Qemu-devel] " Stephen Hemminger
2016-09-27 19:56 ` Michael S. Tsirkin
2016-09-27 19:56 ` [Qemu-devel] " Michael S. Tsirkin
2016-09-28 2:28 ` Yuanhan Liu
2016-09-28 2:28 ` [Qemu-devel] " Yuanhan Liu
2016-09-29 15:30 ` Maxime Coquelin
2016-09-29 17:57 ` Michael S. Tsirkin
2016-09-29 20:05 ` Maxime Coquelin
2016-09-29 20:21 ` Michael S. Tsirkin
2016-09-29 21:23 ` Maxime Coquelin
2016-09-30 12:05 ` Maxime Coquelin
2016-09-30 19:16 ` Michael S. Tsirkin
2016-10-10 4:05 ` Yuanhan Liu
2016-10-10 4:17 ` Michael S. Tsirkin
2016-10-10 4:22 ` Yuanhan Liu
2016-10-10 4:25 ` Michael S. Tsirkin
2016-10-10 12:40 ` Maxime Coquelin
2016-10-10 14:42 ` Yuanhan Liu
2016-10-10 14:54 ` Maxime Coquelin
2016-10-11 6:04 ` Yuanhan Liu
2016-10-11 6:39 ` Maxime Coquelin
2016-10-11 6:49 ` Yuanhan Liu
2016-10-03 14:20 ` Maxime Coquelin
2016-10-10 3:37 ` Yuanhan Liu
2016-10-10 3:46 ` Michael S. Tsirkin
2016-10-10 3:59 ` Yuanhan Liu
2016-10-10 4:16 ` Wang, Zhihong
2016-10-10 4:24 ` Michael S. Tsirkin
2016-10-10 4:39 ` Michael S. Tsirkin
2016-10-11 6:57 ` Yuanhan Liu
2016-10-12 3:21 ` Yuanhan Liu
2016-10-12 3:21 ` [Qemu-devel] [dpdk-dev] " Yuanhan Liu
[not found] ` <F5DF4F0E3AFEF648ADC1C3C33AD4DBF16C2409EB@SHSMSX101.ccr.corp.intel.com>
2016-10-13 2:52 ` [Qemu-devel] " Yang, Zhiyong
2016-10-13 2:52 ` [Qemu-devel] [dpdk-dev] " Yang, Zhiyong
2016-10-10 3:50 ` [Qemu-devel] " Yuanhan Liu
2016-10-09 23:20 ` Michael S. Tsirkin
2016-10-09 23:20 ` [Qemu-devel] " Michael S. Tsirkin
2016-10-10 3:03 ` Yuanhan Liu
2016-10-10 3:03 ` [Qemu-devel] " Yuanhan Liu
2016-10-10 3:04 ` Michael S. Tsirkin
2016-10-10 3:04 ` [Qemu-devel] " Michael S. Tsirkin
2016-10-10 3:10 ` Yuanhan Liu
2016-10-10 3:10 ` [Qemu-devel] " Yuanhan Liu
2016-09-26 6:40 ` [PATCH 2/2] net/virtio: " Yuanhan Liu
2016-09-26 18:04 ` Stephen Hemminger
2016-09-29 18:00 ` Michael S. Tsirkin
2016-09-29 18:01 ` Michael S. Tsirkin
2016-11-10 15:18 ` [PATCH 0/2] enables vhost/virtio " Michael S. Tsirkin
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=20160927031158.GA25823@yliu-dev.sh.intel.com \
--to=yuanhan.liu@linux.intel.com \
--cc=dev@dpdk.org \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stephen@networkplumber.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.