From: Jan Kiszka <jan.kiszka@web.de>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: avi@redhat.com, Miguel Di Ciurcio Filho <miguel.filho@gmail.com>,
qemu-devel@nongnu.org, armbru@redhat.com
Subject: [Qemu-devel] Re: [PATCH RFC 0/4] Dumping traffic when using netdev devices
Date: Fri, 16 Jul 2010 17:45:44 +0200 [thread overview]
Message-ID: <4C407EA8.4030506@web.de> (raw)
In-Reply-To: <4C407470.7060403@codemonkey.ws>
[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]
Anthony Liguori wrote:
> 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
>
> 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).
At least I tend to forget this, and then you already have a VM running
without that chain. And it looks like dynamic reconfiguration of the
backend (netdev_del/add) implies hot-removing/adding the frontend as
well. So this is also no option if the guest does not support that. A
bit unhandy.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
prev parent reply other threads:[~2010-07-16 15:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-15 20:22 [Qemu-devel] [PATCH RFC 0/4] Dumping traffic when using netdev devices Miguel Di Ciurcio Filho
2010-07-15 20:22 ` [Qemu-devel] [PATCH RFC 1/4] net/dump: Make pcap structures public Miguel Di Ciurcio Filho
2010-07-15 20:22 ` [Qemu-devel] [PATCH RFC 2/4] net: Introduce NetClientDump and auxiliary functions Miguel Di Ciurcio Filho
2010-07-15 20:22 ` [Qemu-devel] [PATCH RFC 3/4] net/tap: Suggested support for NetClientDump Miguel Di Ciurcio Filho
2010-07-15 20:23 ` [Qemu-devel] [PATCH RFC 4/4] net/slirp: " Miguel Di Ciurcio Filho
2010-07-16 6:34 ` [Qemu-devel] Re: [PATCH RFC 0/4] Dumping traffic when using netdev devices Jan Kiszka
2010-07-16 14:39 ` Miguel Di Ciurcio Filho
2010-07-16 15:06 ` Jan Kiszka
2010-07-16 15:02 ` Anthony Liguori
2010-07-16 15:41 ` Markus Armbruster
2010-07-16 16:14 ` Anthony Liguori
2010-07-16 19:35 ` Miguel Di Ciurcio Filho
2010-07-16 15:45 ` Jan Kiszka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C407EA8.4030506@web.de \
--to=jan.kiszka@web.de \
--cc=anthony@codemonkey.ws \
--cc=armbru@redhat.com \
--cc=avi@redhat.com \
--cc=miguel.filho@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.