From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LY4np-0001sx-Ix for qemu-devel@nongnu.org; Fri, 13 Feb 2009 15:38:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LY4no-0001sL-Ch for qemu-devel@nongnu.org; Fri, 13 Feb 2009 15:38:25 -0500 Received: from [199.232.76.173] (port=33725 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LY4no-0001sH-4d for qemu-devel@nongnu.org; Fri, 13 Feb 2009 15:38:24 -0500 Received: from mail2.shareable.org ([80.68.89.115]:60759) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LY4nn-0003d3-Og for qemu-devel@nongnu.org; Fri, 13 Feb 2009 15:38:23 -0500 Date: Fri, 13 Feb 2009 20:38:19 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 3/4] qemu:virtio-net: Add support for qemu_vlan_rxfilter Message-ID: <20090213203819.GC20328@shareable.org> References: <20090210212841.9760.96780.stgit@kvm.aw> <200902131617.54616.paul@codesourcery.com> <20090213164601.GK18471@shareable.org> <200902131704.49809.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200902131704.49809.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org, Alex Williamson , kvm@vger.kernel.org Paul Brook wrote: > > > A simple "Something changed, please try your filter again" callback > > > automatically covers all these cases. > > > > It doesn't, if tap has no memory of how many clients require a filter. > > I'm talking about a callback for devices requesting an inbound > filter. Devices implementing outgoing (device->vlan) filters just do > as they're told. So am I. > > If tap just answers "YES and installs the kernel filter" or "NO and > > doesn't install the kernel filter" and doesn't remember how many > > clients need a filter, then: > >... > > In other words, tap needs to distinguish three states: > > > >      "1 filter requested and installed in the kernel" > >      ">1 filter requested, none installed in the kernel" > >      "0 filters requested, none installed in the kernel" > > Absolutely not. This is the reason we have separate the "request an incoming > filter" API from the "provide an outgoing filter" callback. It allows the > vlan code to arbitrate in the middle. I'm guessing that "vlan code to arbitrate in the middle" is exactly what I've suggested. Maybe the description was messed up. Substitute something else for "tap" in the above: "The _vlan arbitration code which talks to the tap device_ needs to distinguish three states...". > A vlan is a bus network, not a set of point-point connections. Yes, this is what I've assumed. The callback you suggest for devices requesting an inbound filter will infinite-loop when there's two such devices on the same vlan bus, because each time the callback is called, that device will re-issue its filter request which triggers the callback on the other similar device. Back and forth. To avoid the infinite loop, the vlan code in the middle (if that's where you want it, and I agree) has to distinguish between no inbound filters requested by attached devices, and multiple incompatible inbound filters requested by attached devices. -- Jamie