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
