From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXxLI-0003aR-95 for qemu-devel@nongnu.org; Fri, 13 Feb 2009 07:40:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXxLH-0003Ym-My for qemu-devel@nongnu.org; Fri, 13 Feb 2009 07:40:27 -0500 Received: from [199.232.76.173] (port=45723 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXxLH-0003Yb-Ik for qemu-devel@nongnu.org; Fri, 13 Feb 2009 07:40:27 -0500 Received: from mx20.gnu.org ([199.232.41.8]:30838) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LXxLH-0005QC-8f for qemu-devel@nongnu.org; Fri, 13 Feb 2009 07:40:27 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXxLD-0003VZ-EB for qemu-devel@nongnu.org; Fri, 13 Feb 2009 07:40:26 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 3/4] qemu:virtio-net: Add support for qemu_vlan_rxfilter Date: Fri, 13 Feb 2009 12:40:20 +0000 References: <20090210212841.9760.96780.stgit@kvm.aw> <200902121705.54473.paul@codesourcery.com> <1234462898.25178.277.camel@bling> In-Reply-To: <1234462898.25178.277.camel@bling> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902131240.21150.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: qemu-devel@nongnu.org Cc: kvm@vger.kernel.org, Alex Williamson > - A device requests a filter and is told if the request is successful > =A0 - On success the device may skip it's own filtering > - If another vlan client is added, the following _must_ occur: > =A0 - The "filterer" must clear (remove) the filter > =A0 - The "filteree" must revert to using their own filtering > - If a vlan client is removed, the following _may_ occur: > =A0 - vlan clients are notified that they may retry their filter >.. > The added()/removed() interface feels like the right solution to this. I think your analysis is fundamentally flawed. Firstly I'm not sure the abo= ve=20 holds when going between 1 and 2 clients on a vlan. Even ignoring that, yo= u=20 are making implicit assumptions about when a filter will succeed. If these= =20 assumptions are broken (which seems likely if we ever implement filtering=20 with more than 2 devices on a vlan) they you'll get subtle breakage in ever= y=20 single user of the API. > We could use a changed() function, but it would need to know the > direction of the change, which leads back to the same mechanics. If > there's a better way, please suggest it. Thanks, I still don't see why the device needs to know what's changed. The response= =20 should always be the same: Request a filter, and see if it works. Paul