[ovs-dev] Multiple OVS vswitchd controlling same kernel path?

William Tu u9012063 at gmail.com
Wed Mar 25 15:33:59 UTC 2020

On Wed, Mar 25, 2020 at 08:21:38AM -0700, William Tu wrote:
> On Wed, Mar 25, 2020 at 10:08:14AM -0400, Tim Rozet wrote:
> > Hi All,
> > I've run into this question several times, and several folks have different
> > opinions. I was hoping we could resolve it. The question centers around
> Me too. Thanks for bringing this up.
> > having multiple OVS vswitchd instances in different netns on the same host
> > using kernel data path. In the past several folks have told me this does
> > not work, because there will be potential conflicts in the kernel data
> > path, or each OVS may flush the kernel path flows without regard for
> > what another OVS has programmed. In contrast, some other folks have told me
> > this should work perfectly fine as each OVS has is using its own DPID and
> > there should be 0 conflicts.
> There is a talk about this in 2015 mentioning a couple of issues
> https://www.openvswitch.org/support/ovscon2015/17/1555-benc.pdf
> Maybe we could go over and test issues in this slide?
> but in reality, I do see people running multiple ovs-vswitcd in multiple
> containers sharing one ovs kernel datapath, without any problem.
> > 
> > One use case around this is being able to use Kubernetes In Docker (KIND),
> > where we are running multiple Docker containers acting as "nodes" with ovs
> > containers inside them, to simulate a large k8s deployment on a single
> > host. Antrea has added support for using netdev mode and claims that kernel
> > data path with multiple OVS will not work:
> > https://github.com/vmware-tanzu/antrea/issues/14
> > https://github.com/vmware-tanzu/antrea/blob/master/docs/kind.md#why-is-the-yaml-manifest-different-when-using-kind
> > 
How about doing this experiment:
1) start 2 containers
2) in each container, run 'make check-kernel' or 'make check-kmod' at the same time
3) see if test cases passed or behave the same as single container

More information about the dev mailing list