From: Cornelia Huck <cohuck@redhat.com>
To: Siwei Liu <loseweigh@gmail.com>
Cc: Sridhar Samudrala <sridhar.samudrala@intel.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
virtio-dev@lists.oasis-open.org
Subject: Re: [virtio-dev] [PATCH] content: Introduce VIRTIO_NET_F_STANDBY feature
Date: Fri, 20 Jul 2018 11:14:03 +0200 [thread overview]
Message-ID: <20180720111403.7803623e.cohuck@redhat.com> (raw)
In-Reply-To: <CADGSJ23ZWOomQ7eJ+3Uj9t1UOvDtRtM-e1ObunSjXYhwqG=xww@mail.gmail.com>
On Fri, 20 Jul 2018 01:41:00 -0700
Siwei Liu <loseweigh@gmail.com> wrote:
> On Thu, Jul 19, 2018 at 2:29 PM, Sridhar Samudrala
> <sridhar.samudrala@intel.com> wrote:
> > VIRTIO_NET_F_STANDBY feature enables hypervisor to indicate virtio_net
> > driver to act as a standby for another device with the same MAC address.
> You should use another feature bit to represent the match-by-MAC
> grouping. I think VIRTIO_NET_F_STANDBY is more of a failover concept
> and shouldn't marry to any grouping mechanism. What you propose simply
> kills off the possibility of introducing other grouping mechanisms
> which don't rely on MAC address at all.
I disagree. VIRTIO_NET_F_STANDBY as used by the Linux driver today does
indicate matching by MAC, so it makes sense for the spec to define it
that way.
We should use new feature bits for any alternative matching mechanisms.
We probably can either
- introduce new features (VIRTIO_NET_F_STANDBY_UUID or so) for any
distinct matching mechanism, or
- introduce VIRTIO_NET_F_STANDBY2 (for the concept) and different
features for different matching mechanisms (including by MAC) which
depend on it.
The problem is that we already have code around that relies on the
semantic of "VIRTIO_NET_F_STANDBY gets you a standby device with the
same MAC", so we can't just redefine it in the spec. An unfortunate
effect of merging something that does not have a proper spec and not
even an agreed semantic :/
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
prev parent reply other threads:[~2018-07-20 9:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-19 21:29 [virtio-dev] [PATCH] content: Introduce VIRTIO_NET_F_STANDBY feature Sridhar Samudrala
2018-07-20 7:44 ` Cornelia Huck
2018-07-22 15:37 ` Michael S. Tsirkin
2018-07-23 9:03 ` Cornelia Huck
2018-07-23 9:22 ` Michael S. Tsirkin
2018-07-23 9:30 ` Cornelia Huck
2018-07-20 8:41 ` Siwei Liu
2018-07-20 9:14 ` Cornelia Huck [this message]
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=20180720111403.7803623e.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=loseweigh@gmail.com \
--cc=mst@redhat.com \
--cc=sridhar.samudrala@intel.com \
--cc=virtio-dev@lists.oasis-open.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.