Flavio, Guru, thank you both for sharings! On Wed, Apr 29, 2015 at 1:25 AM, Flavio Leitner <[email protected]> wrote: > On Tue, 28 Apr 2015 07:06:28 -0700 > Gurucharan Shetty <[email protected]> wrote: > >> On Mon, Apr 27, 2015 at 11:19 PM, Han Zhou <[email protected]> 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 _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
