[ovs-dev] OVS and macvtap - statistics

K.R Kishore krkishore at yahoo.com
Mon Jun 10 23:42:49 UTC 2013


Hi Jesse
Thanks for responding. 
I agree that it looks like it not going completely through the OVS..there seems to be some traffic that goes through though.
I created the bridges following the instructions in 


http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=INSTALL.KVM;hb=HEAD

I used the KVM Virtual Machine manager to add the NIC hardware to an exisitng VM and it appears that all the interfaces are macvtap. From what I could gather this was just a new device driver model to replace the tun/tap model (http://virt.kernelnewbies.org/MacVTap). Is OVS not supported on this? Should I create the bridge in different way? Do I need to create a new VM after creating the bridge always?

thx,
Kishore





>________________________________
> From: Jesse Gross <jesse at nicira.com>
>To: K.R.Kishore <krkishore at yahoo.com> 
>Cc: "dev at openvswitch.org" <dev at openvswitch.org> 
>Sent: Monday, June 10, 2013 2:50 PM
>Subject: Re: [ovs-dev] OVS and macvtap - statistics
> 
>
>Given the difference in numbers, it seems like the majority of packets
>aren't really flowing through OVS at all. I re-read your message and
>noticed this time that you are using macvtap. Why is that? It's likely
>sending packets directly to the NIC, bypassing OVS.
>
>On Fri, Jun 7, 2013 at 8:52 PM, K.R.Kishore <krkishore at yahoo.com> wrote:
>> Hi Jesse
>> Thanks for responding.
>>
>> I checked this earlier and it does not add up. I looked at the delta before and after I ran the netperf test for 10s on a 10G link ( I get ~6G with my current parameters). The ifconfig numbers are in the ballpark for 10s of transmission at ~6G, but the ovs-dpctl numbers are nowhere close.
>>
>> Any other clues?
>> Thx
>>
>> - Kishore
>>
>> On Jun 7, 2013, at 5:56 PM, Jesse Gross <jesse at nicira.com> wrote:
>>
>>> On Fri, Jun 7, 2013 at 11:46 AM, K.R Kishore <krkishore at yahoo.com> wrote:
>>>> Hi
>>>> I am trying to understand the statistics from ovs-dpctl and reconcile that
>>>> with stats from other tools. I am finding it difficult to make sense of the
>>>> numbers, perhaps someone can point me to some documentation about how this
>>>> works? There are numerous links on the web and it is quite confusing as I am
>>>> not sure which is authoritative.
>>>>
>>>> My setup is as follows:
>>>>
>>>> Two machines connected back-to-back via 10G NICs
>>>> Both machines running RHEL 6.4/ wKVM; Two VMs on each, both running CentOS
>>>> 6.4
>>>> OVS 1.10 installed on both;
>>>> Created bridge (ovsbr0) and connected the VMs via macvtap (bridge mode
>>>> -allegedly; VMM says bridge mode, but the host cannot VM and vice-versa; VMs
>>>> can communicate with external hosts/VMs)
>>>>
>>>> I also have linux bridges (br0 & br1) on these VMs but they bridge the VMs
>>>> to different physical ports (p4p1 and em1)
>>>>
>>>> Ran netperf (and netserver) between host1-vm1 and host2-vm1successfully; got
>>>> stats from neperf
>>>>
>>>> I have attached the stats outputs from ovs-dpctl, ifconfig -a and  ip -s
>>>> link and I cannot reconcile these:
>>>> - The port numbers do not match across these, but I can ignore that for now
>>>> - The Rx packets and bytes from ovs-dpctl (port 2: p4p2) does not match (or
>>>> come close to) the ipconfig -a p4p2  or 'ip -s link' (for p4p2)
>>>> - The macvtap ports do show the traffic coming out of the VMs (I see the
>>>> increments in the same ballpark when I run netperf and observe through ip -s
>>>> link and ipconfig -a)
>>>> -
>>>>
>>>> Is all traffic going through OVS bridge (ovsbr0)? Does ovs-dpctl count show
>>>> something? Do I need to enable statistics somewhere?
>>>
>>> OVS tracks packets that have flowed through the switch since the port
>>> was connected whereas the interface statistics show counts since boot.
>>> My guess is that accounts for the difference.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20130610/e9fe8979/attachment-0003.html>


More information about the dev mailing list