[ovs-discuss] ovs-docker: why need to use veth pair instead of internal port?

Han Zhou zhouhan at gmail.com
Wed Apr 29 15:13:24 UTC 2015


Flavio, Guru, thank you both for sharings!

On Wed, Apr 29, 2015 at 1:25 AM, Flavio Leitner <fbl at sysclose.org> wrote:
> On Tue, 28 Apr 2015 07:06:28 -0700
> Gurucharan Shetty <shettyg at nicira.com> wrote:
>
>> On Mon, Apr 27, 2015 at 11:19 PM, Han Zhou <zhouhan at gmail.com> wrote:
>> > Hi Shan,
>> >
>> > Thanks, but why can't we just add an internal port to OVS bridge and
>> > put into namespace?
>> > And what's the native support mentioned in INSTALL.docker.md?
>> You can do it, and its performance is a lot better. But
>
> I recently tested both and didn't notice any significant performance
> gains between veth pairs and internal ports.  Actually the numbers were
> very close and the code difference seems to be only the very beginning
> part the stack where veth has to find out it's for the OVS datapath and
> veth scrubbing the packet.  Other than that, the code path is pretty
> much the same.
>
That's surprising. Could you share the actual throughput you achieved?

> Also, veth does the right thing scrubbing the packet when crossing
> the namespace which internal ports don't do and could be considered a
> security issue.
>
>> 1. once a OVS internal port has been moved inside a namespace, the
>> ovs-vswitchd daemon running in the root namespace can no longer see it
>> and starts complaining.
>
> Yes, when querying ovsdb some of the values (ifindex, mac_in_use,
> stats) relies on the interface's name which is not available to the
> OVS daemon, so it doesn't work properly.
>
Yes, I saw the log: ioctl(SIOCGIFINDEX) on test0 device failed: No such device
But I wonder why send/recv packets still work. In the function
netdev_linux_send() it also needs to call netdev_get_ifindex().
Openstack Neutron dhcp use internal ports in namespaces, and there's
no problem AFAIK, except the warning logs "No such device" when the
ports are being putting to netns.

>> 2. If you are depending on network counters to figure out how much
>> packets have gone through etc, it gets confusing.
>> 3. When you upgrade your kernel module, the internal interfaces will
>> disappear from inside the container, likely causing unexpected
>> behavior for the applications running inside and you will also need a
>> mechanism to move them all back in after the interface are re-created.
>>
>> So to take the easier path, ovs-docker utility does not use OVS
>> internal interfaces but rather uses veth pairs.
>
> Even if the issues above get fixed, the final result is a vswitch where
> the port is not available in the vswitch namespace and the other netns
> has a vswitch port which imposes some limitations, i.e. can you add the
> port to another bridge?
>

Make sense. So it seems not worth the effort of replacing veth pairs
by internal ports, if there is no or little performance penalty,
according to your test results.

> fbl


Han



More information about the discuss mailing list