|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: [PATCH RFC 0/4] Dumping traffic when using netdev devices |
Date: | Fri, 16 Jul 2010 11:14:39 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100528 Lightning/1.0b1 Thunderbird/3.0.5 |
On 07/16/2010 10:41 AM, Markus Armbruster wrote:
Anthony Liguori<address@hidden> 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=barIs 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
[Prev in Thread] | Current Thread | [Next in Thread] |