> The 4096 limitation is something that I keep thinking back to as an > unfortunate limitation. I wish I had a good alternative to propose, but > I don't. Do you have any additional thoughts on it? I agree that it is a limitation. The reason that I have not been very worried about them right of the bat are the following. * Containers do consume quite a bit of resources. As applications running inside them do need CPU and memory resources. So a lot of containers may not be very common. Even when they are, they may share common network resources (example: pods) * Having 4096 OVS interfaces will stress OVS. Addition of new interfaces and their management will be slow. So there is a performance penalty.
> > I think it's worth some extra consideration up front as this isn't a > completely isolated implementation detail. IIUC, whatever is doing > container management has to implement this part to hook up the container > to ovs inside the VM to add the tags to the container traffic, so it > doesn't seem like something that can be trivially changed later without > some extra effort to provide a staged transition with backwards > compatibility. Alternative that I have thought about is QinQ. But OVS currently does not support QinQ (But from what I understand based on some discussions, QinQ support in OVS is addable.) If we decide midway to shift to QinQ, I see the following changes needed: * The container network plugin will need to be upgraded. * The OVN north bound schema will need to be upgraded. * OVN controller will need a change to understand the context. Ben/Justin probably have more insight. > > -- > Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
