[ovs-discuss] vport-patch functionality in mainstream

[Konstantin Khorenko]

Hi Jesse,

thank you very much for your reply, please see inline.

On 07/06/2012 06:11 AM, Jesse Gross wrote:
> On Wed, Jul 4, 2012 at 9:27 AM, Konstantin Khorenko<khorenko at openvz.org>  wrote:
>> Hi,
>>
>> we'd like to add the Open vSwitch kernel module to OpenVZ kernel,
>> in order to do that we've backported the appropriate code from mainstream
>> kernel.
>>
>> It turned out that the vport-patch functionality could be also very useful
>> for us,
>> so we are looking for possibility to include it to our kernel as well.
>>
>> Unfortunately mainstream does not have vport-patch functionality at the
>> moment and
>> porting vport-patch related code from openvswitch.org git and incorporating
>> it into
>> the code taken from mainstream appeared to be not a straightforward task.
>>
>> On the other hand i've found that Open vSwitch FAQ says:
>> "Work is in progress in adding these features ["patch" in particular] to the
>> upstream Linux version of the Open vSwitch kernel module."
>
> The FAQ doesn't contain the phrase that you added in brackets so what
> you have here is very misleading.  The work that this refers to is
> tunneling.

Well, i really appreciate your clarification about this, honestly i was under
impression that those paragraphs are not only about tunneling, may be it's
worth to make the sentences a bit more precise so nobody misreads them like me.

>> So can you please clarify:
>> * is that info in FAQ still valid and the work for "patch" inclusion in
>> mainstream is in progress?
>> * i failed to find any preliminary patches in the web, but if you have any -
>>    can you please share it or just tell me where should i look for it?
>
> There's no work in progress or planned to add patch ports upstream.
> I'm not enthusiastic about doing it either as I would like to remove
> uses of it rather than add more.
>
> What is your use case?

So, our case is the following:
let's assume we have a Node with physical interfaces ethX and a set of
Containers (CTs)/Virtual Machines (VMs) with virtual interfaces which are visible on the Node as vethY.

We plan to implement the following scheme:

---[br0 (eth0)]---
---[br1 (eth1)]---
---[brX (ethX)]------[vbrX (vethA, vethB, ...)]
		  ---[vbrZ (vethM, vethN, ...)]


So we want to create a number of bridges - one per physical interface on the Node,
each bridge contains the corresponding physical interface.

Node administrator might want group CTs/VMs:
a) CTs/VMs with interfaces bridged with a particular physical interface on the node (there can
      be several such groups surely)
b) CTs/VMs with the "host only" access

So we'd like to create separate bridges for all groups from a), as well as for groups b) and c).

If the administrator decides that CTs/VMs from group G should work in the bridged mode via
physical interface P, we simply connect brP and vbrG with help of "patch" functionality.

There are several advantages of this scheme:
1) if the administrator needs to reconfigure CTs/VMs group G to work via physical
      interface P1, all we need is to destroy the original "patch" connection with brP and create
      another one with brP1.
2) adding a new CT/VM to any group (or even stopping/starting an old one) does not lead to brX
      bridges MAC address changes, consequently network connections to any CT/VM in the group will
      not be affected (this problem arises if we use a single bridge for both physical interface
      and virtual ones).


So here is what we plan to implement.
Please let me know in case something is unclear here, and any comment and suggestions are highly appreciated.

Thank you in advance.

--
Konstantin Khorenko