From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXf0j-00089N-6A for qemu-devel@nongnu.org; Thu, 12 Feb 2009 12:06:01 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXf0g-000872-GX for qemu-devel@nongnu.org; Thu, 12 Feb 2009 12:06:00 -0500 Received: from [199.232.76.173] (port=56437 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXf0g-00086n-BZ for qemu-devel@nongnu.org; Thu, 12 Feb 2009 12:05:58 -0500 Received: from mx20.gnu.org ([199.232.41.8]:13896) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LXf0f-0007mX-RZ for qemu-devel@nongnu.org; Thu, 12 Feb 2009 12:05:57 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXf0e-0005vJ-K2 for qemu-devel@nongnu.org; Thu, 12 Feb 2009 12:05:56 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 3/4] qemu:virtio-net: Add support for qemu_vlan_rxfilter Date: Thu, 12 Feb 2009 17:05:53 +0000 References: <20090210212841.9760.96780.stgit@kvm.aw> <200902121626.58977.paul@codesourcery.com> <1234456607.25178.177.camel@bling> In-Reply-To: <1234456607.25178.177.camel@bling> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902121705.54473.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 On Thursday 12 February 2009, Alex Williamson wrote: > On Thu, 2009-02-12 at 16:26 +0000, Paul Brook wrote: > > > +static void virtio_net_vlan_client_added(void *opaque) > > >... > > > +static void virtio_net_vlan_client_removed(void *opaque) > > > > Why are these two different? > > > > It looks like what you really want is a callback for "Something changed, > > and you need to reset your MAC filter." > > I think we'd end up with a race if we only had one callback. For > instance if "change" was the result of a vlan client being removed, the > tap would clear the filter and the nic would try to install a filter. > The results would be different based on the calling order. In that case either your implementation or your abstraction is wrong. Devices shouldn't need to know or care why a filter failed to apply. I'm not sure what you mean by "the tap would clear the filter". You have three options: - Devices request a filter, and that request may fail. qemu notifies the device when it needs to retry the filter. It doesn't make any difference whether we think we just broke the old filter, or we think a previously failed filter may succeed now, the device response is the same: Try to set a filter and see if it works. This is what I assume you're trying to implement. - Implement reliable filters. The device requests a filter once[1]. qemu makes sure that filter is always honored. - Devices request a filter once. qemu remembers what that filter is, and notifies the device if/when that filter becomes active/inactive. Paul [1] once == every time the filter set changes.