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

[Nithin Raju]

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