From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LVLQs-0007QL-Fm
	for qemu-devel@nongnu.org; Fri, 06 Feb 2009 02:47:26 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LVLQq-0007Q9-UO
	for qemu-devel@nongnu.org; Fri, 06 Feb 2009 02:47:25 -0500
Received: from [199.232.76.173] (port=50667 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LVLQq-0007Q6-PD
	for qemu-devel@nongnu.org; Fri, 06 Feb 2009 02:47:24 -0500
Received: from mx2.redhat.com ([66.187.237.31]:54045)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <markmc@redhat.com>) id 1LVLQq-0006s2-6w
	for qemu-devel@nongnu.org; Fri, 06 Feb 2009 02:47:24 -0500
From: Mark McLoughlin <markmc@redhat.com>
In-Reply-To: <20090206044853.3116.46699.stgit@kvm.aw>
References: <20090206044853.3116.46699.stgit@kvm.aw>
Content-Type: text/plain
Date: Fri, 06 Feb 2009 07:47:19 +0000
Message-Id: <1233906439.3673.20.camel@blaa>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH][RFC] qemu:virtio-net: Use TUNSETTXFILTER
 for MAC filtering
Reply-To: Mark McLoughlin <markmc@redhat.com>, qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alex Williamson <alex.williamson@hp.com>
Cc: qemu-devel@nongnu.org

On Thu, 2009-02-05 at 21:51 -0700, Alex Williamson wrote:
> Now that virtio-net knows what packets the guest wants to see, we
> can start moving the filtering down the stack.  This patch adds
> an interface to set the software filter in the tap device.  It's
> fairly limited, but we can back it up with our own filtering if it
> overflows.

Looks good to me.

Note also the new world order where we don't handle qemu_malloc()
failures.

> Here are a couple issues I'm still pondering:
>  - Is the fd_rx_filter() interface sufficiently generic
>  - Should vlan_set_hw_rx_filter() live in net.c or elsewhere
>  - Is it ok to call fd_rx_filter() against all the vlan clients.  I
>    exit on the first one, which covers the simple config.

All of these are related to the problem that we're trying to add
optimizations for the simple config (i.e. one NIC associated with one
tap interface) without any clean representation of the simple config in
the API.

It's not strictly needed in this case - the VLAN API for setting filters
could aggregate the filters of all VLAN clients - but what you really
want is to only have the filter apply if virtio-net is paired with a tap
interface.

Cheers,
Mark.