[ovs-dev] [PATCH 00/14] datapath-windows: Implement the rest of the netlink vport commands

[Samuel Ghinet]

Hello guys, 

This patch number 00 is an introduction to the patch series.

I am sorry we could not provide the design behind this much faster. This series of patches is based on that design.
I have tested these vport commands with both VMs and vxlan, with both VMs connecting and reconnecting and netlink vport add-s and deletes.

In order to work properly, this patch requires a few fixes in parts that are outside of this series' scope:
1. netdev-windows - I received from Alin a draft patch, which was enough to allow the userspace use the netlink commands vport new, set and delete
2. nl transaction fix: 
  function nl_sock_transact_multiple__: 
[CODE]
        if (!DeviceIoControl(sock->handle, OVS_IOCTL_TRANSACT,
                             ofpbuf_data(txn->request),
                             ofpbuf_size(txn->request),
                             txn->reply ? tail : 0,
                             txn->reply ? sizeof tail : 0,
                             &reply_len, NULL)) {
            /* XXX: Map to a more appropriate error. */
            error = EINVAL;
            break;
        }
[/CODE]
txn->reply must always be non-null. Even though the highest caller (the one that requested, e.g., vport set) does not need the reply, it will still be needed in by the lower callers to log netlink error, etc.
Please look on the linux version: there, if the transaction's reply is NULL, a temporary transaction with a temporary buffer is used instead.

3. datapath command new - for the purpose of this testing, the datapath command new was implemented the same as datapath command set. ovs-vswitchd uses netlink command datapath new.
4. The WMI / powershell script.

------------------------------

Known issues and things to consider:
1. Each creation of a bridge in the userspace results in a creation of an internal port in the kernel.
This means that if you have br-int and br-pif, two ports will attempt to be created: one br-pif and the other br-int.
This current implementation will successfully create the first internal port, but will fail the second, because it expects that only one internal port to exist.
It is possible the correct method to solve this to be clear once we have most or all of the netlink functionality implemented, so that we will see if it is important to differentiate in kernel from "source port = br-int" and "source-port = br-pif".
Or, if we can leave the second and the n-th  internal ports dummy, i.e. without their hyper-v switch port counterpart.

NOTE: On linux, the datapath new command also creates the vport LOCAL (port number 0), which is a reserved port. From what can be figured, we need create this port, and the userspace doesn't need to receive it.

2. the port "external" is currently created from userspace by requesting a netlink command vport new with port name "external". The hyper-v switch can have only one external NIC.
 If other method is preferred (e.g. setting name with WMI), it can be later modified so.

NOTE: From what I have noticed as the MS forwarding sample did, this driver keeps the external port separate from the list of ports. There is no need to do this, and it is more consistent to put the external port in the port list / hash array as the rest are.

3. this series of patches also added the port number < MAXUINT16 constraint, so that in userspace, the vport channels would work.