[ovs-dev] OVS and macvtap - statistics
jesse at nicira.com
Tue Jun 11 01:39:36 UTC 2013
I would strongly recommend using the native support for OVS in libvirt
rather than manually connecting bridges and ports together. There are
a number of tutorials floating around, so hopefully you can find one
for your distribution.
macvtap is primarily intended for getting packets out to the network
without applying any policies locally, so it will bypass OVS. It's not
really a direct replacement for taps.
On Mon, Jun 10, 2013 at 4:42 PM, K.R Kishore <krkishore at yahoo.com> wrote:
> 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
> 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?
> 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?
>> - 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:
>>>> I am trying to understand the statistics from ovs-dpctl and reconcile
>>>> with stats from other tools. I am finding it difficult to make sense of
>>>> numbers, perhaps someone can point me to some documentation about how
>>>> 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
>>>> 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;
>>>> can communicate with external hosts/VMs)
>>>> I also have linux bridges (br0 & br1) on these VMs but they bridge the
>>>> to different physical ports (p4p1 and em1)
>>>> Ran netperf (and netserver) between host1-vm1 and host2-vm1successfully;
>>>> 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
>>>> - The Rx packets and bytes from ovs-dpctl (port 2: p4p2) does not match
>>>> 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
>>>> 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.
More information about the dev