[ovs-dev] datapath-windows: adding vport from userspace to kernel

[Samuel Ghinet]

Thanks Nithin,

This netdev check on windows, I understand, would translate to a km-um / netlink communication by which it will be checked if the hyper-v switch does have a port with friendly name X.
The only thing that remains is to be sure that when that vnic disconnects, a vport delete will happen (I assume this is the expected behavior).

Sam
________________________________________
From: Nithin Raju [nithin at vmware.com]
Sent: Thursday, September 11, 2014 4:31 AM
To: Samuel Ghinet; Alin Serdean
Cc: dev at openvswitch.org
Subject: datapath-windows: adding vport from userspace to kernel

hi Sam/Alin,
This is a followup to the discussion we had over IRC this morning about adding vports.

The question was about what should happen in the kernel if userspace tries to add a VIF port that is not existent on the hyper-v switch. Should we support it?

In general, you cannot add a vport to the kernel from userspace that does not exist in the system. Eg. if you try to add a vport (using ovs-vsctl add-port) using its user friendly name that does not exist on the hyper-v switch, vswitchd flags this as a failure. The reason for the failure is this piece of code in bridge.c:

iface_do_create():
1698     error = netdev_open(iface_cfg->name,
1699                         iface_get_type(iface_cfg, br->cfg), &netdev);
1700     if (error) {
1701         VLOG_WARN_BUF(errp, "could not open network device %s (%s)",
1702                       iface_cfg->name, ovs_strerror(error));
1703         goto error;
1704     }

I understand that netdev_open() is not implemented on Windows. But, when it does get implemented, it should be done in such a way that it return success only if a VM's NIC (VIF) is connected to the hyper-v switch.

This way, we can make an assumption in the OVS kernel code that if there's a request to add a vport that corresponds to a VIF, userspace had validated that such an VIF exists on the system.

We still need to figure out a lot of things, but one thing for sure is that in the kernel we won't have to store ports that are not non-existent on the hyper-v switch.

Thanks,
-- Nithin