Ask Your Question

Why is OVS patch used instead of veth pairs to connect OVS bridges?

asked 2016-01-17 06:39:33 -0600

Dragos gravatar image

The explanation I've seen is that the OVS patch interface is optimized for OpenvSwitch. I would like to understand what is being optimized.

I've seen a reply on the OVS mailing list that says OVS patch ports are implemented entirely inside OVS userspace. I don't understand how this is done without a performance penalty. I've thought that as soon a VM sends a packet to its vNIC, the packet will cross from user space to kernel space over the TAP interface. Eventually the packet reaches the OVS bridge (br-int, for example). If at that point the packet must be sent to next OVS bridge over a patch port, does it mean it crosses back to user space? That would incur a performance hit.

I am hypothesizing that perhaps the patch port is just a configuration construct to tell the OVS kernel module that the ports on two OVS bridges are connected. Then, somehow the kernel module is able to forward the packets between the two bridges more efficiently than over a veth pair. It would be nice if somebody can confirm if this is the correct explanation or if there is a better one.

edit retag flag offensive close merge delete


See or uploaded by me It addresses the question professionally

dbaxps gravatar imagedbaxps ( 2016-01-17 10:58:18 -0600 )edit

2 answers

Sort by ยป oldest newest most voted

answered 2016-01-17 08:07:24 -0600

dbaxps gravatar image

updated 2016-01-17 13:25:59 -0600

UPDATE MSK 22:25 01/17/2015
Due to reference
Network flow patch-tun => patch-int and vice/versa is using kernel datapath.

You wrote "I am hypothesizing that perhaps the patch port is just a configuration construct to tell the OVS kernel module that the ports on two OVS bridges are connected. "

Are all features available with all datapaths?
A: Open vSwitch supports different datapaths on different platforms. Each datapath has a different feature set: the following tables try to summarize the status.
Supported datapaths:
1. Linux upstream: The datapath implemented by the kernel module shipped with Linux upstream. Since features have been gradually introduced into the kernel, the table mentions the first Linux release whose OVS module supports the feature.
2. Linux OVS tree: The datapath implemented by the Linux kernel module distributed with the OVS source tree. Some features of this module rely on functionality not available in older kernels: in this case the minumum Linux version (against which the feature can be compiled) is listed.
3.Userspace: Also known as DPDK, dpif-netdev or dummy datapath. It is the only datapath that works on NetBSD and FreeBSD.
4. Hyper-V: Also known as the Windows datapath.

See table right down in original document

> Looking at the log file (ovs-vswitchd.log below), it seems that Open vSwitch
> is looking for the kernel module to be loaded. Does this mean that userspace
> open vSwitch does not support VXLAN functionality?
Yes, that's correct. Only the Linux kernel datapath supports tunneling.

So in picture bellow (Snapshot on RDO Kilo Controller/Network )

  Bridge br-int
        fail_mode: secure
        Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}
        Port "tap7107e523-3c"
            tag: 1
            Interface "tap7107e523-3c"
                type: internal
        Port "qr-5181525f-08"
            tag: 1
            Interface "qr-5181525f-08"
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
    Bridge br-tun
        fail_mode: secure
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "vxlan-0c000089"
            Interface "vxlan-0c000089"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="", out_key=flow, remote_ip=""}
        Port br-tun
            Interface br-tun
                type: internal
        Port "vxlan-0c00009d"
            Interface "vxlan-0c00009d"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="", out_key=flow, remote_ip=""}
    ovs_version: "2.3.1"

So , Openstack Kilo (LIberty) with ML2&OVS&VXLAN setup is using kernel datapath
BR-TUN is connected to BR-INT via {patch-int,patch-tun} and vice/versa

My guess is that flow patch-tun => patch-int (vice/versa) is using kernel data-path as well
edit flag offensive delete link more


Thanks for the detailed answer!

Dragos gravatar imageDragos ( 2016-01-17 13:44:04 -0600 )edit

I believe there is OVS mailing list, which will suite your question better then this forum. At least your question would be addressed by person with in depth knowledge of the most recent OVS status.

dbaxps gravatar imagedbaxps ( 2016-01-17 14:48:07 -0600 )edit

answered 2016-01-17 07:22:06 -0600

Personally I think that Neutron strives to use as little Linux networking (bridges, veth pairs) as possible. If it were not for the iptables-based security groups, not even qbr-s (which are currently Linux bridges) would exist. I think that is where OVN is headed, a pure-openvswitch, full-featured virtualized networking.

Speaking about the userspace crossing, you surely know that in OpenvSwitch only the first packet in a flow hits the user space. Based on that one, a datapath flow is created in kernel space and all subsequent traffic matching the flow goes directly through kernel space. If you haven't tried already, look closer at ovs-dpctl, particularly the show and dump-flows subcommands. I'm sure you will find any flow that passes through the patch ports there.

edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools



Asked: 2016-01-17 06:39:33 -0600

Seen: 5,177 times

Last updated: Jan 17 '16