From: Anthony Liguori <anthony@codemonkey.ws>
To: Miguel Di Ciurcio Filho <miguel.filho@gmail.com>
Cc: avi@redhat.com, jan.kiszka@web.de, 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 10:02:08 -0500 [thread overview]
Message-ID: <4C407470.7060403@codemonkey.ws> (raw)
In-Reply-To: <1279225380-28790-1-git-send-email-miguel.filho@gmail.com>
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).
Regards,
Anthony Liguori
> Bugs/limitations:
> - I have no clue on how to deal with tap+vhost, is it necessary?
> - When using virtio-net, I'm not sure how to handle iovec when vnet_hdr=on
> - Create a function to add dump to a netdev on the fly, is it necessary?
> - Handle cleanups
>
> Miguel Di Ciurcio Filho (4):
> net/dump: Make pcap structures public
> net: Introduce NetClientDump and auxiliary functions
> net/tap: Suggested support for NetClientDump
> net/slirp: Suggested support for NetClientDump
>
> net.c | 90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> net.h | 8 +++++
> net/dump.c | 21 -------------
> net/dump.h | 21 +++++++++++++
> net/slirp.c | 3 ++
> net/tap.c | 3 ++
> qemu-common.h | 1 +
> 7 files changed, 126 insertions(+), 21 deletions(-)
>
>
next prev parent reply other threads:[~2010-07-16 15:02 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 [this message]
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
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=4C407470.7060403@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=armbru@redhat.com \
--cc=avi@redhat.com \
--cc=jan.kiszka@web.de \
--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.