Add extentions to the standard datapath interface

The datapath interface defined in odp-netlink.h needs some extensions
that are platform dependent. Some examples are the name of the communication
device on Windows and a set of commands that are specific to Windows.

In this change we define a datapath-windows/include/OvsDpInterfaceExt.h
to include any platform specific interface extensions.

OvsDpInterfaceExt.h is in turn included in odp-netlink.h ONLY for _WIN32.
This approach was chosen to avoid including OvsDpInterfaceExt.h directly
although the latter approach is as good as the former.

Also, we define three ioctls in OvsDpInterfaceExt.h:
read:     provides an output buffer (mimics a recv)
write:    provides an input buffer (mimics a send)
transact: provides an input and optionally an output buffer.
          (mimics a send followed by recv)

Signed-off-by: Nithin Raju <nithin@vmware.com>
Co-Authored-by: Ben Pfaff <blp@nicira.com>
Acked-by: Alin Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Saurabh Shah <ssaurabh@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: Add Datapath.[ch] and OVS_USE_NL_INTERFACE CPP

In this change we create peer to OvsIoctl.[ch] that would interface
with userspace using the netlink interface. The new files are called
Datapath.[ch]. We are not deleting OvsIoctl.[ch] yet. Datapath.[ch]
provides bare minimum functionality to register a pseudo device for
communication with userspace.

We also define a CPP called OVS_USE_NL_INTERFACE in the ovsext project.
This defines if the old interface (pre-netlink based) or the new
interface (netlink- based) should be enabled in the kernel. By default,
the value is 0 since the Datapath.[ch] are minimal. In the next change,
we'll turn it to 1.

Since Datapath.[ch] containes code copied from OvsIoctl.[ch], acking
the original author as well.

Signed-off-by: Nithin Raju <nithin@vmware.com>
Co-authored-by: Guolin Yang <gyang@vmware.com>
Acked-by: Alin Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Saurabh Shah <ssaurabh@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: add infrastructure for supporting netlink

In this change, we define netlink families and commands supported
by the Windows datapath. Only the control family and one command
is supported today to get the PID.

We also implement the 3 ioctls: read, write and transact. This is
bare minimum and can be used to implement the equivalent of a
recv, send, and send-recv in userspace netlink. This interface
is subject to change as iron out the details of the user-kernel
interface for operations around packet receive, events, dump, etc.

We also turn on OVS_USE_NL_INTERFACE to 1 in the ovsext project.

Signed-off-by: Nithin Raju <nithin@vmware.com>
Acked-by: Alin Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Saurabh Shah <ssaurabh@vmware.com>
Reported-at: https://github.com/openvswitch/ovs-issues/issues/18
Signed-off-by: Ben Pfaff <blp@nicira.com>
netlink-socket.c: implement get pid support on Windows

To verify if the netlink support in the kernel works, I updated
the netlink-socket.c code to get the PID for a given device
descriptor.

In the existing code, userspace sets the PID, which will not be
unique across different processes. So, it is better for the
kernel to generate the PID and give it back to userspace.

dpif-linux.c was ported to Windows (similar to Alin's change in
the cloudbase repo) and was able to exercise the code changes
in netlink-socket.c to read the PID. dpif-linux.c changes are
not being checked in.

Signed-off-by: Nithin Raju <nithin@vmware.com>
Acked-by: Alin Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Saurabh Shah <ssaurabh@vmware.com>
Reported-at: https://github.com/openvswitch/ovs-issues/issues/18
Signed-off-by: Ben Pfaff <blp@nicira.com>