Thanks Yrineu and Subhash! It is also possible that what Shuva comes up with may need a small code change for you to enable it - instead of a documentation change. Shuva will get in touch with you however.
On Thu, Aug 4, 2016 at 11:46 AM, Yrineu Rodrigues <yfrfel...@gmail.com> wrote: > Hi Abhijit, thank you for your attention. The same for us (NIC), we'll add > it on our wiki page. > > With regards, > > On Thu, Aug 4, 2016 at 3:41 PM, Subhash Singh <subhash_singh@ > criterionnetworks.com> wrote: > >> Hello Abhijit, >> >> Please let us (DIDM) know for the required config changes, I will add it >> in didm user documentation. >> >> -- >> Thanks and Regards, >> Subhash Kumar Singh >> >> On Thu, Aug 4, 2016 at 9:47 PM, Abhijit Kumbhare <abhijitk...@gmail.com> >> wrote: >> >>> Hello DIDM & NIC, >>> >>> We are finding the performance of the oper-datastore inventory slow if >>> table features is turned on by default as mentioned by Shuva below. This >>> would affect all the users regardless of whether they use the table >>> features or not. DIDM & NIC are the only ones using the table features. >>> Hence from our OpenFlow Plugin meeting today we decided we will keep the >>> default configuration to be table features off and have DIDM/NIC enable it >>> when they need it. We are still deciding whether we start it off as a >>> config change (most likely) and/or transition it to be a run-time change >>> (less likely in the Boron release). Jozef, Shuva, etc. will follow up later >>> with the instructions - but we would need you to either implement the >>> change to turn it on (if it is a run time option) - or have instructions in >>> your user level documentation to turn it on (config time option). >>> >>> Thanks, >>> Abhijit >>> >>> On Wed, Aug 3, 2016 at 12:58 AM, Shuva Jyoti Kar < >>> shuva.jyoti....@ericsson.com> wrote: >>> >>>> 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:jozef.baci...@pantheon.tech] >>>> *Sent:* Wednesday, August 03, 2016 12:32 PM >>>> *To:* Abhijit Kumbhare; Anil Vishnoi; openflowplugin-dev@lists. >>>> opendaylight.org >>>> *Cc:* Tom Pantelis; Muthukumaran K; Shuva Jyoti Kar; Luis Gomez; >>>> didm-...@lists.opendaylight.org; nic-...@lists.opendaylight.org >>>> *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:abhijitk...@gmail.com >>>> <abhijitk...@gmail.com>] >>>> *Sent:* Wednesday, August 3, 2016 7:37 AM >>>> *To:* Anil Vishnoi <vishnoia...@gmail.com>; openflowplugin-dev@lists. >>>> opendaylight.org >>>> *Cc:* Tom Pantelis <tompante...@gmail.com>; Muthukumaran K < >>>> muthukumara...@ericsson.com>; Shuva Jyoti Kar < >>>> shuva.jyoti....@ericsson.com>; Jozef Bacigál < >>>> jozef.baci...@pantheon.tech>; Luis Gomez <ece...@gmail.com>; >>>> didm-...@lists.opendaylight.org; nic-...@lists.opendaylight.org >>>> *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 <vishnoia...@gmail.com> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Aug 2, 2016 at 10:04 PM, Tom Pantelis <tompante...@gmail.com> >>>> 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 < >>>> muthukumara...@ericsson.com> 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:tompante...@gmail.com] >>>> *Sent:* Wednesday, August 03, 2016 9:46 AM >>>> *To:* Anil Vishnoi >>>> *Cc:* Abhijit Kumbhare; Shuva Jyoti Kar; jozef.baci...@pantheon.tech; >>>> 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 <vishnoia...@gmail.com> >>>> 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 <abhijitk...@gmail.com> >>>> 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 >>>> > <shuva.jyoti....@ericsson.com> wrote: >>>> >> >>>> >> Sure, sounds good. Can you please review the patch and merge it then >>>> ? >>>> >> >>>> >> >>>> >> >>>> >> Thanks >>>> >> >>>> >> Shuva >>>> >> >>>> >> >>>> >> >>>> >> From: Abhijit Kumbhare [mailto:abhijitk...@gmail.com] >>>> >> 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 < >>>> shuva.jyoti....@ericsson.com> >>>> >> 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:abhijitk...@gmail.com] >>>> >> 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 >>>> >> <shuva.jyoti....@ericsson.com> 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 >>>> >> <muthukumara...@ericsson.com> 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:abhijitk...@gmail.com] >>>> >> 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 < >>>> shuva.jyoti....@ericsson.com> >>>> >> 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 >>>> >>>> >>>> >>>> Jozef*Bacigá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 / jozef.baci...@pantheon.tech >>>> reception: +421 2 206 65 114 / www.pantheon.sk >>>> >>>> [image: logo] >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> didm-dev mailing list >>> didm-...@lists.opendaylight.org >>> https://lists.opendaylight.org/mailman/listinfo/didm-dev >>> >>> >> >> _______________________________________________ >> nic-dev mailing list >> nic-...@lists.opendaylight.org >> https://lists.opendaylight.org/mailman/listinfo/nic-dev >> >> > > > -- > *Yrineu Rodrigues* > *OpendayLight NIC PTL/committer* > -- > > *Linkedin <http://www.linkedin.com/in/yrineu>* > *NIC wiki page* > <https://wiki.opendaylight.org/view/Network_Intent_Composition:Main> > >
_______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
