----- "Dor Laor" <dlaor@xxxxxxxxxx> wrote:
> On 08/03/2009 04:51 PM, Michael Goldish wrote:
> > ----- "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?)
>
> It's pretty low. There are various issues with iperf and with windows
>
> registry configurations that can boost it drastically.
>
> > - 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?
> >
>
> From the above, it seems like the overhead is low so you can leave
> the
> tcpdump patch. When we'll do performance testing we should turn it off
> after it traps the dhcp reply.
OK, that's very easy to do -- the test just has to call something like
env["tcpdump"].close() before running iperf.
BTW, can iptables decode DHCP packets too (like tcpdump does), or can
it just log them?
>
> >>>>> - 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
--
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
