Thanks for a detailed explanation Jozef and Michal. Need to digest it more - but a quick question: is this the best way for 4117? Do we need to tweak the way a bit? What about the new recommendation that was provided by the MD-SAL team to use the data tree change listener (DTCL) instead of the Data Change Listener (DCL)?
Yes - we should discuss these in the meeting. I believe you are not there for the next meeting - may be next week we can schedule a one-off additional meeting or change the time for the next week only. On Wed, Mar 23, 2016 at 7:08 AM, Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco) <[email protected]> wrote: > Hi Abhijit, folks > > > - I talked with Michal Rehak about patch 4117 here is the explanation: > > > Bug 4117 introduces backward compatibility with He-design regarding > notifications in He-d. almost all changes were distributed via md-sal > notifications Li-d (thanks to 4117) provides a listener to changes in > DS/operational and redistributes them to apps via md-sal notification > service it is slower than He-d it emulates device's xid by generating > fake value as there is no longer original response available there is one > more draft patch pending where "old-notification-supplier" is renamed to > "notification-supplier" > > > https://git.opendaylight.org/gerrit/#/c/33102/1 > > > - Bug 5464 > > > As we make a workaround with the possibility of switch off the table > features > > > https://git.opendaylight.org/gerrit/#/c/36506/ > > > Michal send another email with the second possibility to change the model > > > original email from Michal: > > > " > Hi guys, > > regarding flows cleaning: in order to keep flows in DS/operational > consistent with device there is different logic for that in Li-design. > Requirements are - stay consistent in cluster even after leader change. So > keeping local cache of flows and computing which flow should be removed > from DS/operational after stats get processed might fail. But removing all > flows before writing fresh reported flows is simple and sufficient strategy > here. It is also faster then removing outdated flows one by one. > > But since ovs-2.4 we have huge data block in table element: > table-features. And by writing table with empty collection of flows these > big table-features are written too. By every statistics response. This is > causing the cpu load and renders controller unusable for more than like 63 > switches (topo=tree,6). > > Switching table-features off via config-subsystem is just a workaround for > testing. > There is better solution - move table-features out of table. But here we > need to ask downstream projects on how they use table-features. If the only > use case relies on rpc then we are good. If DS/config or DS/operational are > involved then we need to adapt these projects. That's why I did not answer > the second question - I have no idea about impact here. > > Also it might be worth to think about evicting table-features out of DS > completely - if the only use case relies on rpc and there is no real > requirement on reading, writing or listening to table-features in DS. > > > So I guess we should discuss table-features with downstreamers as soon as > possible in order to have this fixed by SR2. > > > > Regards, " > > > and here is patch for it: > > > https://git.opendaylight.org/gerrit/#/c/36559/3 > > > > It would be most appreciated to let us on the next meeting decide > which solution we choose into beryllium (maybe both) ... > > Jozef > > > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
