----- "Dor Laor" <dlaor@xxxxxxxxxx> wrote:
> On 08/03/2009 12:39 PM, Michael Goldish wrote:
> > ----- "Dor Laor"<dlaor@xxxxxxxxxx> wrote:
> >
> >> tcpOn 08/03/2009 02:58 AM, Michael Goldish wrote:
> >>> Here's my proposed TAP solution:
> >>> - The user specifies MAC ranges and may or may not specify
> >> corresponding IP
> >>> ranges.
> >>> - VMs are always given MAC addresses from the user specified MAC
> >> ranges.
> >>> - MAC address ranges must be unique to each host running KVM
> tests
> >> -- there
> >>> must be no overlap between them.
> >>> - If corresponding IP ranges are specified as well, the system
> will
> >> use them
> >>> when trying to communicate with guests.
> >>> - If corresponding IP ranges are not specified, tcpdump will be
> used
> >> to listen
> >>> to DHCP traffic and dynamically detect the right IP addresses.
> >> There's also a
> >>> flag that can force this behavior.
> >> This is pretty nice patch set and it's nice and friendly to hook
> the
> >> assigned ip address.
> >> Maybe instead of using tcpdump you can add a specific ip tables
> rule
> >> to
> >> trap dhcp replies and log them?
> >
> > What are the advantages compared to tcpdump? Is it easier?
> > If you look at the tcpdump patch you'll see it's quite short.
> > Most of the code in this set is not related to tcpdump but rather
> to
> > host specific static MAC-IP mapping and other related things.
> > To me the iptables idea sounds a little more complex especially
> since
> > we'll have to deal with host specific configuration -- I'm not even
> sure
> > all hosts run a firewall. What do you think?
>
> iptables config might be a bit harder but on the same scale..
> If you plan to constantly run tcpdump in the background iptables hook
> will be much cheaper.
I run tcpdump with a filter ('dst port 68') that makes it output packets
only very rarely (only when some NIC is assigned an IP address).
To make sure tcpdump doesn't significantly impact performance I ran a
few benchmarks (the host is a core 2 duo machine):
- Local iperf: 8.5 Gbits/sec
- Local iperf with tcpdump running (filtered): 8.5 Gbits/sec
- Local iperf with tcpdump running (unfiltered): 6 Gbits/sec
- Local iperf with 4 instances of tcpdump (filtered): 7.3 Gbits/sec
- Local iperf with 4 instances of tcpdump (unfiltered): 3.3 Gbits/sec
- iperf between a Windows VM (virtio) and a host: 240 Mbits/sec (is that normal?)
- Same thing, with tcpdump (filtered): 240 Mbits/sec
- Same thing, with tcpdump (unfiltered): 240 Mbits/sec
- Same thing, with 4 instances of tcpdump (filtered): 240 Mbits/sec
- Same thing, with 4 instances of tcpdump (unfiltered): 200 Mbits/sec
If I understand correctly, this means that running tcpdump with a filter
minimizes the performance penalty involved.
(Note that for KVM tests we only need a single instance of tcpdump, even
when several VMs run at the same time.)
In light of this, do you still fear tcpdump will involve a significant
performance penalty? Do you think these benchmarks mean anything or
did I make a mistake somewhere that rendered them meaningless?
> >>> - tcpdump will run in the background at all times, and collect
> >> MAC-IP pairs
> >>> as soon as they are assigned by the DHCP server. This is useful
> >> for
> >>> NIC hotplugging (where IP addresses are assigned during the test
> >> itself) and
> >>> generally for misbehaving guests or DHCP servers (restarting
> network
> >> services
> >>> during the test, using very short lease times).
> >>> - It is up to the user to create the actual bridge for TAP
> devices;
> >> the
> >>> qemu-ifup script included in one of the patches only adds the TAP
> >> interface to
> >>> an existing bridge. The user should modify this script or create
> a
> >> bridge
> >>> some other way.
> >>>
> >>> This works very well on two hosts I tried, but I'm not entirely
> sure
> >> it will
> >>> work in all cases -- please let me know what you think.
> >>>
> >>> (I remember Jason Wang mentioned that tcpdump doesn't always
> catch
> >> all the
> >>> required traffic, or that it might somehow depend on the DHCP
> server
> >> -- anyone
> >>> willing to comment on that?)
> >>>
> >>> The following patches have been tested with a few KVM tests
> (boot,
> >> reboot,
> >>> stress_boot, migration) with both TAP and user mode, but they
> could
> >> probably
> >>> use more testing (maybe with Python 2.6?), so if anyone is
> willing
> >> to help
> >>> with that I'd appreciate it very much.
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe kvm" in
> >>> the body of a message to majordomo@xxxxxxxxxxxxxxx
> >>> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
