qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC v2 PATCH 5/4 PATCH] virtio-net: send gratuitous pa


From: Michael S. Tsirkin
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
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Oct 24, 2011 at 02:54:59PM +1030, Rusty Russell wrote:
> On Sat, 22 Oct 2011 13:43:11 +0800, Jason Wang <address@hidden> 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 <address@hidden>
> 
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]