Comment 5 for bug 1639186

@armax, yes, you're right, I also remember pointing out that patch ports were a better solution in those cases during the specs review.

Luis Tomas tried, and internal can't be used to link ovs bridges, he's trying veths now.

I'm sure veths wouldn't work with DPDK, and they also come with performance degradation, because the packets will jump in/out (ovs), veth, in/out(ovs) ... :/

But apparently there is people interested in containers without dpdk, who want to set qos constraints on the ports.

We need to think about how to satisfy the case if veths finally works. I guess here it boils down to two options:

1) Having a config flag to set them all as veths if the operator is interested in this specific case, which would work, but would not be very friendly to mixed environments, and it adds another config switch (puaghhh)

2) Signaling (somehow) trunk ports that we want the specific port wired as a veth, may be through a callback (BEFORE_QOS_BWLIMIT_APPLIED???), so if trunk ports is there will drop the patch and put a veth in place. If trunk port is not there, that would be ignored. And if there is any other extension which uses patch ports, we also give them the opportunity to move down to veths.