hi Folks,
Following are my findings (not many) from looking at netdev and how to go about
implementing it for Windows. I'm posting this as followup to the discussion we
had during IRC meeting. Pls. feel free to comment.
For reference, I looked at the code in the VMware repo (prior to opensourcing)
where there was an implementation of netdev-windows.c. I looked in the
Cloudbase repo, but I could not find a netdev-windows.c and the changes in
netdev-linux.c were very minimal to call it ported code. Maybe it is, and I
missed something.
The hierarchy is something like this:
netdev.c
|
-------> netdev-vport.c implements netdev for tunnel ports, eg
"gre"/"vxlan" etc.
|
-------> netdev-[linux|bsd].c implement netdev for
"system"/"tap"/"internal" ports.
To quote from the "PORTING" guide:
The "system" type corresponds to an existing network device on the system.
OVS_VPORT_TYPE_NETDEV maps to "system", and "OVS_VPORT_TYPE_INTERNAL" maps to
"internal". Each platform has to implement the ability to open these devices as
a 'netdev'. So, basically, we'll have to implement netdev-windows.c for the two
types of ports - "system" and "internal". We cannot directly leverage
netdev-linux.c unlike we did for dpif-linux.c.
We have two options:
1) Use Windows APIs such as GetAdaptersInfo() to query the details of a network
interface on the Windows host. Eitan suggested that we use Object Notifier.
-----------
a) The upside of this approach is that we don't need to add new commands to the
OVS kernel, and netdev-windows.c can call into APIs.
b) The downsides are:
* In order to enumerate the output of the Windows APIs, we'll need to figure
out the unique IDs of the ports, and these unique IDs are different from the
names maintained by OVS. So, we'll probably need some help from WMI or from OVS
kernel to map the OVS names to Windows IDs. Eg. I'd imagine something like
querying the UUID from the OVS kernel, and then using this UUID in the WMI /
Windows APIs.
* APIs such as GetAdaptersInfo() return only the adapters on the Windows
host. They don't return the adapters on the Virtual machines. So, we'll have to
use a combination of APIs. I am yet to figure out the correct APIs to use for
Virtual Machine adapters. We'll have to mostly use WMI calls for this.
* Overall, lot of code to write.
2) Implements command in OVS kernel datapath that are outside of the standard
set to retrieve the the required information about each port
-----------
a) The downside of this approach is that OVS kernel may not have all the
information that netdev needs. Eg. driver information etc. But, it is quite
straight forward for the most required information such as ethernet address,
MTU etc.
b) The upsides are:
* There's already code in the OVS kernel for such command:
OVS_IOCTL_VPORT_EXT_INFO. This command will have to be added to the Windows
extensions interface in OvsDpInterfaceExt.h, and the output has to be wrapped
in a netlink message.
* It is quite straight forward and reliable for the most required
information such as ethernet address, MTU etc.
Overall, IMO, it is best to go with approach #2. As mentioned in #2a, it might
turn out that we'll have to use Windows APIs anyway for port information that
is not available from OVS kernel, but that can come in later, IMO. For now, if
we can use the OVS_IOCTL_VPORT_EXT_INFO and get the basic information, it
should be good for boot strapping OVS.
Thanks,
-- Nithin
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
