[ovs-dev] Design notes for provisioning Netlink interface from the OVS Windows driver (Switch extension)
aserdean at cloudbasesolutions.com
Thu Aug 7 17:49:48 UTC 2014
Do you have any particular reason to support both devices for start instead of focusing on the Netlink interface?
On the patches progressing a bit slower than expected spent a bit too much time on the issue https://github.com/openvswitch/ovs-issues/issues/10 but I may have an idea which I would like to talk about in the next meeting. I plan to work in the weekend though to get so we can be one step close to our goal :).
De la: Eitan Eliahu [mailto:eliahue at vmware.com]
Trimis: Thursday, August 7, 2014 3:19 AM
Către: Alin Serdean; dev at openvswitch.org; Rajiv Krishnamurthy; Ben Pfaff; Kaushik Guha; Ben Pfaff; Justin Pettit; Nithin Raju; Ankur Sharma; Samuel Ghinet; Linda Sun; Keith Amidon
Subiect: RE: Design notes for provisioning Netlink interface from the OVS Windows driver (Switch extension)
The driver which is currently checked in (the original one) supports the DPIF interface through a device object registered with the system. This driver works with a private version of user mode OVS (i.e. dpif-windows.c). The secondary device would be a second device object which supports the Nelink interface. For the initial development phase both devices will be instantiated and registered in the system. Thus, we could bring up all transaction and dump based DPIF commands over the Netlink device while the system is up and running.
For clarity, let's call the "original device" the "DPIF device" and the "secondary device" the "Netlink device".
From: Alin Serdean [mailto:aserdean at cloudbasesolutions.com]
Sent: Wednesday, August 06, 2014 4:28 PM
To: Eitan Eliahu; dev at openvswitch.org; Rajiv Krishnamurthy; Ben Pfaff; Kaushik Guha; Ben Pfaff; Justin Pettit; Nithin Raju; Ankur Sharma; Samuel Ghinet; Linda Sun; Keith Amidon
Subject: RE: Design notes for provisioning Netlink interface from the OVS Windows driver (Switch extension)
> C. Implementation work flow:
> The driver creates a device object which provides a NetLink interface
> for user mode processes. During the development phase this device is created in addition to the existing DPIF device. (This means that the bring-up of the NL based user mode can be done on a live kernel with resident DPs, ports and flows) All transaction
> and dump based DPIF functions could be developed and brought up when the NL device is a secondary device (ovs-dpctl show and dump XXX should work). After > the initial phase is completed (i.e. all transaction and dump based DPIF primitives are implemented), the original device interface will be removed and packet and
> event propagation path will be brought up (driven by vswicth.exe)
Could you, please explain a bit more what does original/secondary device mean?
More information about the dev