From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXL6N-0004Gd-AX for qemu-devel@nongnu.org; Wed, 11 Feb 2009 14:50:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXL6L-0004GP-Gg for qemu-devel@nongnu.org; Wed, 11 Feb 2009 14:50:30 -0500 Received: from [199.232.76.173] (port=49019 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXL6L-0004GM-7E for qemu-devel@nongnu.org; Wed, 11 Feb 2009 14:50:29 -0500 Received: from g4t0015.houston.hp.com ([15.201.24.18]:6658) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LXL6K-0004ov-PB for qemu-devel@nongnu.org; Wed, 11 Feb 2009 14:50:29 -0500 From: Alex Williamson In-Reply-To: <1234380678.14052.238.camel@blaa> References: <20090210212841.9760.96780.stgit@kvm.aw> <1234380678.14052.238.camel@blaa> Content-Type: text/plain Date: Wed, 11 Feb 2009 12:51:06 -0700 Message-Id: <1234381866.7026.1524.camel@lappy> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/4] qemu: TAP filtering support Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark McLoughlin Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org Hi Mark, Thanks for the comments. On Wed, 2009-02-11 at 19:31 +0000, Mark McLoughlin wrote: > > - The logic around "is this a NIC+TAP pair?" would be good to have a > better API around. We need this to merge virtio GSO support too. > Anthony had some ideas here. Ok, I'll see if I can dig that up. > - I think you could keep the client_added()/removed() logic in net.c > and things would be a lot cleaner. I think you just want to trigger > a reload of the filter, right? So a "reload this filter" callback > to qemu_vlan_rxfilter() might do it. In this series, the vlan doesn't maintain state for the filter, so a reload requires interaction of the NIC backend. Anthony had requested a common software filter that would make something like you're suggesting easier, but I'm still wrestling with the nuances of how that might work. Things like the e1000 multicast hash throw a kink in the plan, which left me with each NIC needing to re-enable it's own filtering when another client is added. > - What do we need rxfilter=on|off on the command line for? Primarily because the current tun driver in Linux has a bug that it can drop unicast packets requested to be included in the filter if it overflows the exact match table. http://www.spinics.net/lists/netdev/msg88451.html Thanks, Alex