The reasons I see we'd need to support both devices would be to keep the rest functionality working while we replace a part with its netlink counterpart.
[QUOTE]The two-device approach is for us to make sure that we are getting things correctly. Eg. what is the output of flow dump in one device, v/s the other device. I don't think any of the userspace code will have to worry about it.[/QUOTE] I don't think this would be of much help. I mean, the greatest problems, I believe, would come up as parsing the netlink attributes wrongly, or writing the writing the reply as netlink attributes wrongly (if you decide on implementing your own netlink parser in kernel). At least for "datapath", "vport" (add, new, delete, set, dump) and "flow" operations. Sam ________________________________________ From: Eitan Eliahu [elia...@vmware.com] Sent: Thursday, August 07, 2014 8:57 PM To: Alin Serdean; dev@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) Hi Alin, yes, we want to exercise the interface when OVS is running. For example we would like to dump the flow table is not empty. On the other issue (NBL with multiple NBs, Github issue #10) I think we need to talk how to support it. After you came across this issue we even know how to produce this case :-) Thanks, Eitan -----Original Message----- From: Alin Serdean [mailto:aserd...@cloudbasesolutions.com] Sent: Thursday, August 07, 2014 10:50 AM To: Eitan Eliahu; dev@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) Hi Eithan, 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://urldefense.proofpoint.com/v1/url?u=https://github.com/openvswitch/ovs-issues/issues/10&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yTvML8OxA42Jb6ViHe7fUXbvPVOYDPVq87w43doxtlY%3D%0A&m=EXUTxzeugqhErQ2Fi%2BVBW0vsf89O8ECLmGTTV1lNZX0%3D%0A&s=70afc8a789fbcf2c754809a1f9d1246227250b279dd35e740bbb31b34544bc6b 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 :). Alin. -----Mesaj original----- De la: Eitan Eliahu [mailto:elia...@vmware.com] Trimis: Thursday, August 7, 2014 3:19 AM Către: Alin Serdean; dev@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) Hi Alin, 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". Eitan -----Original Message----- From: Alin Serdean [mailto:aserd...@cloudbasesolutions.com] Sent: Wednesday, August 06, 2014 4:28 PM To: Eitan Eliahu; dev@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) Hi Eitan, > 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? Ty! Alin. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
