[ovs-dev] Implementation for netlink based interface on Windows

Nithin Raju nithin at vmware.com
Tue Aug 5 00:54:58 UTC 2014

This is a followup to the discussion on 7/29 between the VMware and the
Cloudbase teams working on OVS for Hyper-V, regarding Netlink based interface
implementation between kernel and userspace.

It was agreed that VMware folks would look at the kernel code posted on 7/29 by
Cloudbase team, and evaluate as to how to adapt the Kernel code that got checked
in to talk Netlink. Also, the userspace patches checked in by Cloudbase for
netlink support would also be reviewed. Cloudbase mentioned that they have some
pending patches.

The end goal is to come up with an approach for the Netlink adoption, and try to
split the work among the various developers in the two teams (or more). Hence
this document:

1) What we have and is committed in OVS repo:
1a) Support for netlink sockets in Windows. (commits by Cloudbase in netlink-
socket.c and friends). The netlink socket handles are wrappers to the Windows
HANDLEs returned by CreateDevice*().
1b) Non-netlink interface based Kernel support developed by VMware.

2) What we have and is NOT committed:
2a) Support for Netlink messages (both family and type) in the Kernel developed
by Cloudbase, and the corresponding functionality triggered by the messages.
2b) A Windows port of dpif-linux.c (that uses netlink of course). (Our
impression was this was checked in).

3) What we are trying to develop:
3a) Steps for userspace Netlink support (Cloudbase):
- Get dpif-linux.c to work on Windows. Get a clean version that would be able
to talk to the Kernel using the interface defined in openvswitch.h.

3b) Steps for the Kernel Netlink support (VMware):
3b1) Define a openvswitch-windows.h in include/windows to contain definitions
of the user-kernel interface that are specific to Windows. Eg. the name of the
pseudo device.
3b2) Creates a peer to OvsIoctl.[ch] that would interface with netlink based
3b3) Adding support for parsing of netlink messages. Currently there's already
support for nl_attr in OvsNetlink.h.

Overall, VMware folks feel that it would be better for Cloudbase to work on #3a,
and VMware folks to work on #3b. This is mostly due to code familiarity of the
respective teams.

Getting these initial steps taken care of will let the userspace and kernel talk
to each other. Once we have this, it would speed up implementation since it
would be easier to chunk up the work and distribute it.

We'll discuss more during the IRC meeting, but this document hopefully serves as
a basis.

-- Nithin

More information about the dev mailing list