From: "Michael S. Tsirkin" <mst@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: aliguori@us.ibm.com, kvm@vger.kernel.org, quintela@redhat.com,
jan.kiszka@siemens.com, Jason Wang <jasowang@redhat.com>,
qemu-devel@nongnu.org, blauwirbel@gmail.com,
netdev@vger.kernel.org, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [RFC v2 PATCH 5/4 PATCH] virtio-net: send gratuitous packet when needed
Date: Mon, 24 Oct 2011 07:25:26 +0200 [thread overview]
Message-ID: <20111024052526.GA2362@redhat.com> (raw)
In-Reply-To: <87ty6z10f8.fsf@rustcorp.com.au>
On Mon, Oct 24, 2011 at 02:54:59PM +1030, Rusty Russell wrote:
> On Sat, 22 Oct 2011 13:43:11 +0800, Jason Wang <jasowang@redhat.com> wrote:
> > This make let virtio-net driver can send gratituous packet by a new
> > config bit - VIRTIO_NET_S_ANNOUNCE in each config update
> > interrupt. When this bit is set by backend, the driver would schedule
> > a workqueue to send gratituous packet through NETDEV_NOTIFY_PEERS.
> >
> > This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE.
> >
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
>
> This seems like a huge layering violation. Imagine this in real
> hardware, for example.
commits 06c4648d46d1b757d6b9591a86810be79818b60c
and 99606477a5888b0ead0284fecb13417b1da8e3af
document the need for this:
NETDEV_NOTIFY_PEERS notifier indicates that a device moved to a
different physical link.
and
In real hardware such notifications are only
generated when the device comes up or the address changes.
So hypervisor could get the same behaviour by sending link up/down
events, this is just an optimization so guest won't do
unecessary stuff like try to reconfigure an IP address.
Maybe LOCATION_CHANGE would be a better name?
> There may be a good reason why virtual devices might want this kind of
> reconfiguration cheat, which is unnecessary for normal machines,
I think yes, the difference with real hardware is guest can change
location without link getting dropped.
FWIW, Xen seems to use this capability too.
> but
> it'd have to be spelled out clearly in the spec to justify it...
>
> Cheers,
> Rusty.
Agree, and I'd like to see the spec too. The interface seems
to involve the guest clearing the status bit when it detects
an event?
Also - how does it interact with the link up event?
We probably don't want to schedule this when we detect
a link status change or during initialization, as
this patch seems to do? What if link goes down
while the work is running? Is that OK?
--
MST
next prev parent reply other threads:[~2011-10-24 5:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-22 5:43 [Qemu-devel] [RFC v2 PATCH 5/4 PATCH] virtio-net: send gratuitous packet when needed Jason Wang
2011-10-24 4:24 ` Rusty Russell
2011-10-24 5:25 ` Michael S. Tsirkin [this message]
2011-10-24 9:11 ` Ben Hutchings
2011-10-25 2:50 ` Jason Wang
2011-10-25 15:41 ` Michael S. Tsirkin
2011-10-26 4:49 ` Jason Wang
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=20111024052526.GA2362@redhat.com \
--to=mst@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=blauwirbel@gmail.com \
--cc=jan.kiszka@siemens.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=rusty@rustcorp.com.au \
/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).