From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [PATCH 0/4] qemu: TAP filtering support Date: Wed, 11 Feb 2009 12:51:06 -0700 Message-ID: <1234381866.7026.1524.camel@lappy> References: <20090210212841.9760.96780.stgit@kvm.aw> <1234380678.14052.238.camel@blaa> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org To: Mark McLoughlin Return-path: Received: from g4t0015.houston.hp.com ([15.201.24.18]:6659 "EHLO g4t0015.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753980AbZBKTu1 (ORCPT ); Wed, 11 Feb 2009 14:50:27 -0500 In-Reply-To: <1234380678.14052.238.camel@blaa> Sender: kvm-owner@vger.kernel.org List-ID: 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