From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 0/4] qemu: TAP filtering support Date: Wed, 11 Feb 2009 13:43:01 -0600 Message-ID: <49932A45.20601@codemonkey.ws> References: <20090210212841.9760.96780.stgit@kvm.aw> <1234380678.14052.238.camel@blaa> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Williamson , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Mark McLoughlin Return-path: Received: from qw-out-2122.google.com ([74.125.92.26]:39405 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750760AbZBKTnc (ORCPT ); Wed, 11 Feb 2009 14:43:32 -0500 Received: by qw-out-2122.google.com with SMTP id 5so184681qwi.37 for ; Wed, 11 Feb 2009 11:43:30 -0800 (PST) In-Reply-To: <1234380678.14052.238.camel@blaa> Sender: kvm-owner@vger.kernel.org List-ID: Mark McLoughlin wrote: > Hi Alex, > > Just had a quick looked over these and they seem pretty good, but some > broad comments: > > - 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. > Right now, the networking API is based on VLANs and VLAN clients. This is fine for a simple interface of sending/receiving packets one at a time. When you want to support special features (like filtering, GSO) or want to supply many receive buffers, this falls apart because the VLAN client needs to consider what features are supported by every other VLAN client and also deal with things like hot add/remove from a VLAN. A better architecture IMHO would be to have a NIC backend/frontend architecture. This provides a rather simple interface to support feature negotiation and optimizes the interface for the common case (one VLAN client per VLAN). You would then implement the VLAN layer as a NIC backend. The user-visible interface wouldn't change at all. You could even go as far as to special case the circumstance where you had a VLAN containing one host device and one guest device and simply avoid using the VLAN at all. Regards, Anthony Liguori > - 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. > > - What do we need rxfilter=on|off on the command line for? > > Cheers, > Mark. > > > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >