From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RID1Y-0006yl-Af for qemu-devel@nongnu.org; Mon, 24 Oct 2011 01:24:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RID1R-0001Gu-Bz for qemu-devel@nongnu.org; Mon, 24 Oct 2011 01:24:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RID1O-0001Ev-Gn for qemu-devel@nongnu.org; Mon, 24 Oct 2011 01:24:27 -0400 Date: Mon, 24 Oct 2011 07:25:26 +0200 From: "Michael S. Tsirkin" Message-ID: <20111024052526.GA2362@redhat.com> References: <20111022054311.21798.3340.stgit@dhcp-8-146.nay.redhat.com> <87ty6z10f8.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ty6z10f8.fsf@rustcorp.com.au> Subject: Re: [Qemu-devel] [RFC v2 PATCH 5/4 PATCH] virtio-net: send gratuitous packet when needed List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rusty Russell Cc: aliguori@us.ibm.com, kvm@vger.kernel.org, quintela@redhat.com, jan.kiszka@siemens.com, Jason Wang , qemu-devel@nongnu.org, blauwirbel@gmail.com, netdev@vger.kernel.org, pbonzini@redhat.com On Mon, Oct 24, 2011 at 02:54:59PM +1030, Rusty Russell wrote: > On Sat, 22 Oct 2011 13:43:11 +0800, Jason Wang 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 > > 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