On 07/16/2010 10:41 AM, Markus Armbruster wrote:
Anthony Liguori<anth...@codemonkey.ws> 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
