From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48595 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZnYo-0005Jr-Bi for qemu-devel@nongnu.org; Fri, 16 Jul 2010 12:14:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZnYm-0004ZJ-P7 for qemu-devel@nongnu.org; Fri, 16 Jul 2010 12:14:49 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:41541) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZnYm-0004Yu-Kg for qemu-devel@nongnu.org; Fri, 16 Jul 2010 12:14:48 -0400 Received: by pwi2 with SMTP id 2so897787pwi.4 for ; Fri, 16 Jul 2010 09:14:47 -0700 (PDT) Message-ID: <4C40856F.9010403@codemonkey.ws> Date: Fri, 16 Jul 2010 11:14:39 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH RFC 0/4] Dumping traffic when using netdev devices References: <1279225380-28790-1-git-send-email-miguel.filho@gmail.com> <4C407470.7060403@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: jan.kiszka@web.de, Miguel Di Ciurcio Filho , avi@redhat.com, qemu-devel@nongnu.org On 07/16/2010 10:41 AM, Markus Armbruster wrote: > Anthony Liguori writes: > > >> On 07/15/2010 03:22 PM, Miguel Di Ciurcio Filho wrote: >> >>> Hello, >>> >>> This is a prototype suggestion. I mostly copied and pasted the code from >>> net/dump.c into net.c and made some adjustments. There is no command line >>> parsing involved yet, just the internals and small changes in net/tap.c and >>> net/slirp.c do make the thing work. >>> >>> In my tests, using tap as backend, e1000 as a guest device and running iperf from >>> guest to host, the overhead of dumping the traffic caused a loss of around 30% >>> of performance. >>> >>> I opened the dumped files in wireshark and they looked fine. When using slirp >>> all requests were dumped fine too. >>> >>> >> A less invasive way to do this would be to chain netdev devices. >> >> Basically: >> >> -netdev tap,fd=X,id=foo >> -netdev dump,file=foo.pcap,netdev=foo,id=bar >> -net nic,model=virtio,netdev=bar >> > Is this really less invasive? It breaks the simple 1:1 relationship > between NIC and network backend. All the code dealing with > VLANClientState member peer needs to be touched. For instance, this is > the code to connect peers, in qemu_new_net_client(): > > if (peer) { > assert(!peer->peer); > vc->peer = peer; > peer->peer = vc; > } > The peering code should all disappear. I thought that's the whole point of this exercise? I think the main advantage is we avoid adding special logic to handle dumping. If we never have a case like this again, then perhaps it doesn't matter. > Possibly worth it if we had a number of different things we want to > insert between the end points, but I don't see that right now. > > >> I think this has some clear advantages to this architecturally. From >> a user perspective, the only loss is that you have to add the dump >> device at startup (you can still enable/disable capture dynamically). >> > I don't like this restriction at all. > I don't either but I don't think it's a deal breaker. I'm really open to either approach but I just wanted to make sure this one was considered. Regards, Anthony Liguori