First take – with even one switch connected the restconf hangs when we try querying the oper-DS via apidoc. Over Postman its extremely slow. And avoid oper-Ds writes for applications that might not require this.
It would be really nice to measure the performance for scaled out scenarios – switch scaleout + large config( a mil flows scenario ) Thanks, shua From: Jozef Bacigál [mailto:[email protected]] Sent: Wednesday, August 03, 2016 12:32 PM To: Abhijit Kumbhare; Anil Vishnoi; [email protected] Cc: Tom Pantelis; Muthukumaran K; Shuva Jyoti Kar; Luis Gomez; [email protected]; [email protected] Subject: RE: Patch for tuning table features Hi guys, Sorry I wasn’t here for two days, but first thing the patch seems good. Second thing I see no problem when the table features stay switched ON. Before the changes the table features were inside the tables and with each table we always loaded full features. Now are the features on the same level as table so performance in boron get better. It would be nice to have some performance test with ON/OFF table features with this patch set. Jozef From: Abhijit Kumbhare [mailto:[email protected]] Sent: Wednesday, August 3, 2016 7:37 AM To: Anil Vishnoi <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: Tom Pantelis <[email protected]<mailto:[email protected]>>; Muthukumaran K <[email protected]<mailto:[email protected]>>; Shuva Jyoti Kar <[email protected]<mailto:[email protected]>>; Jozef Bacigál <[email protected]<mailto:[email protected]>>; Luis Gomez <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: Patch for tuning table features Yes - we should reach out to DIDM & the NIC project - but I want to also discuss this in this week's meeting. I have added the OpenFlow Plugin mailing list - as well as DIDM & NIC - so they can be aware of this discussion. If I remember right we had also discussed this earlier - don't remember what we had concluded then. On Tue, Aug 2, 2016 at 10:31 PM, Anil Vishnoi <[email protected]<mailto:[email protected]>> wrote: On Tue, Aug 2, 2016 at 10:04 PM, Tom Pantelis <[email protected]<mailto:[email protected]>> wrote: So you have some apps that need table-features enabled but other apps that need it off? That sounds like a deployment headache - what if an end user has installed an app that needs it on and also an app that needs it off? What happens to an app if the setting isn't what it needs? It's moreover like, some apps need it, but apps who don't need it, would *prefer* to disable it for performance reason. So if it comes to the situation where one app need table features, then other app will have to live with it. But yes, it's still an deployment options, and we were thinking an easy way for doing that. Regardless, this seems like a deployment option for the end user or integrator, ie let the user decide what to set it to rather than apps trying to set it automatically on install and possibly stomping over one another. So if a user installs DIDM, document that they must enable table-features. This is also reasonable option, but not sure if didm and nic projects are okay with it or not. This might add some work on their plate to fix their intergration/csit jobs etc. Abhijit, do you think it make sense to reach out to DIDM/NIC project? On Wed, Aug 3, 2016 at 12:29 AM, Muthukumaran K <[email protected]<mailto:[email protected]>> wrote: So, assuming that a set of projects require default-value for a config param (table-features in this case) to be true, they would have use what comes out of box (assuming that XML what we ship via features.xml sets the value to true). Then another set of projects want to flip – they stop the whole karaf container, edit this XML and restart. Or they can edit the XML file on fly ? Clarity of this sequence may be useful for how test automation runs CSIT – a set of Test suites which require the value to be true (in this example, DIDM, NIC) and another set of test suites which require this value to be false (everything else other than NIC or DIDM) Regards Muthu From: Tom Pantelis [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, August 03, 2016 9:46 AM To: Anil Vishnoi Cc: Abhijit Kumbhare; Shuva Jyoti Kar; [email protected]<mailto:[email protected]>; Muthukumaran K Subject: Re: Patch for tuning table features If using clustered-app-config, the default value can be set via an external XML file that could be shipped via a features.xml. See https://wiki.opendaylight.org/view/Using_Blueprint#Using_the_Datastore On Tue, Aug 2, 2016 at 6:08 PM, Anil Vishnoi <[email protected]<mailto:[email protected]>> wrote: I think two project had dependent (DIDM and NIC) on the table features. So if plugin will disable it now, both the project will break. So if we want to disable table features, we need to provide some solution on how these project can enable it. Given that all the config nobs are present in data store, didm/nic project can overwrite the default value to false, but that will restart the openflowplugin model, which i think should be fine. Tom, do you have any other thoughts on how projects can set value of config nob exposed by dependent projects? On Tue, Aug 2, 2016 at 2:25 PM, Abhijit Kumbhare <[email protected]<mailto:[email protected]>> wrote: > Added Jozef. Since it is Jozef's patch and you are now a committer - you can > review/merge it :) > > On Mon, Aug 1, 2016 at 11:57 PM, Shuva Jyoti Kar > <[email protected]<mailto:[email protected]>> wrote: >> >> Sure, sounds good. Can you please review the patch and merge it then ? >> >> >> >> Thanks >> >> Shuva >> >> >> >> From: Abhijit Kumbhare >> [mailto:[email protected]<mailto:[email protected]>] >> Sent: Tuesday, August 02, 2016 12:25 PM >> >> >> To: Shuva Jyoti Kar >> Cc: Muthukumaran K; Anil Vishnoi >> Subject: Re: Patch for tuning table features >> >> >> >> We should ask DIDM to turn it on if and when they need it. >> >> On Monday, August 1, 2016, Shuva Jyoti Kar >> <[email protected]<mailto:[email protected]>> >> wrote: >> >> I do see your point Abhjit. The spec says “If it wishes to understand the >> size, types, and order in which tables are consulted, the controller >> >> sends a OFPMP_TABLE_FEATURES multipart request (see A.3.5.5)”. Hence it >> would be optional. Am I correct ? >> >> >> >> But if we turn it off by , will any projects have a problem ? I remember >> DIDM having a dependency. >> >> The current status that exists for the He and Li designs are: >> >> >> >> Master >> >> >> >> He-design: turned on by default, can be turned off >> >> Li-design :mandatory now[my patch will make it configurable] >> >> >> >> Stable/Be >> >> >> >> He-design: turned on by default, can be turned off >> >> Li-design: turned off by default as per >> https://git.opendaylight.org/gerrit/#/c/36506/4 >> >> >> >> I do see a point it making it off by default. Do let me know if I am >> missing something >> >> >> >> Thanks >> >> Shuva >> >> >> >> From: Abhijit Kumbhare >> [mailto:[email protected]<mailto:[email protected]>] >> Sent: Tuesday, August 02, 2016 5:20 AM >> To: Shuva Jyoti Kar >> Cc: Muthukumaran K; Anil Vishnoi >> Subject: Re: Patch for tuning table features >> >> >> >> The spec does not say that the table features HAS to be used. I think we >> should turn it off on both the He and the Li designs to keep consistent >> assuming it is causing enough performance problems. >> >> >> >> On Sat, Jul 30, 2016 at 7:47 PM, Shuva Jyoti Kar >> <[email protected]<mailto:[email protected]>> wrote: >> >> Absolutely Muthu ,nothing else. Aligining with the spec its been turned on >> but can be turned off in a manner that aligns with the implementation on the >> He plugin as well. >> >> On Sun, Jul 31, 2016 at 2:53 AM, Muthukumaran K >> <[email protected]<mailto:[email protected]>> wrote: >> >> >> >> It was kept on just to be in alignment with spec and also with He plugin’s >> config >> >> >> >> Anything else Shuva ? >> >> >> >> Regards >> >> Muthu >> >> >> >> >> >> From: Abhijit Kumbhare >> [mailto:[email protected]<mailto:[email protected]>] >> Sent: Sunday, July 31, 2016 2:52 AM >> To: Shuva Jyoti Kar >> Cc: Anil Vishnoi; Muthukumaran K >> Subject: Re: Patch for tuning table features >> >> >> >> Then shouldn't it be off by default if OVS 2.4 is sending a lot of data >> and performance suffers? >> >> On Saturday, July 30, 2016, Shuva Jyoti Kar >> <[email protected]<mailto:[email protected]>> >> wrote: >> >> Hi Anil, Abhijit, >> >> >> >> I have pushed a patch for turning table-features ON/OFF with the >> li-plugin. By default it is on, but can be switched off. >> >> >> >> https://git.opendaylight.org/gerrit/#/c/42821/1 >> >> >> >> We need this fix since by default ovs2.4 sends quite a huge amount of data >> for each switch connected. >> >> >> >> Could you please review the change and let me know your comments. >> >> >> >> Thanks >> >> Shuva >> >> > > -- Thanks Anil -- Thanks Anil JozefBacigál Software Engineer Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia R&D centrum / Janka Kráľa 9 / 974 01 Banská Bystrica / Slovakia +421 908 766 972 / [email protected]<mailto:[email protected]> reception: +421 2 206 65 114 / www.pantheon.sk<http://www.pantheon.sk> [logo]
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
