Alin, 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.
Like Eitan was mentioning in the previous mail, if we can get a ported dpif-linux.c, that should be sufficient for us. We'll use to this exercise the new NL device interface, and use the old dpif-windows.c to exercise the legacy interface. -- Nithin On Aug 7, 2014, at 10:49 AM, Alin Serdean <aserd...@cloudbasesolutions.com> wrote: > 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=ubrOpIWavCMqX4l4j1LEVpTfDj%2FD5Qyn8KCoJIBGvzo%3D%0A&m=z%2BzFYft67OyIMrbjU76jo6%2Bc7Pf%2F9dQp3vXZYkrIDKY%3D%0A&s=cf4b0dc3b9e800c895b90c3b41a50c6f3fa68f9f06f5c82c3f742b3d1d5810de > 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
