----- "Dor Laor" <dl...@redhat.com> wrote: > On 08/03/2009 04:51 PM, Michael Goldish wrote: > > ----- "Dor Laor"<dl...@redhat.com> wrote: > > > >> On 08/03/2009 12:39 PM, Michael Goldish wrote: > >>> ----- "Dor Laor"<dl...@redhat.com> 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 majord...@vger.kernel.org > >>>>> 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 majord...@vger.kernel.org > >>> 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 majord...@vger.kernel.org > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html