Just a minor correct. Lithium plugin in master branch don't have a flag to disable it. We took an alternate solution to move table-features out of /"node/table" path. I think we should cherry-pick that patch to master as well for LIthium, if we want to disable table features by default.
On Wed, May 25, 2016 at 7:06 PM, Tai, Hideyuki <hideyuki....@necam.com> wrote: > I agree with Anil's and Abhijit's proposal. > > > > Hi Raphael and Renato, > > What do you think about this proposal from the point of view of NIC > committers? > > Since you implemented PipelineManager which uses the table features, > > we need your opinions about if it is acceptable to NIC project or not. > > Actually, I'm still not sure if the PipelineManager really needs the > table features. > > > > By the way, does the table features still generates huge data even after > the model change on the master branch? > > https://git.opendaylight.org/gerrit/#/c/36559/ > > > > Regards, > > Hideyuki Tai > > > > *From:* nic-dev-boun...@lists.opendaylight.org [mailto: > nic-dev-boun...@lists.opendaylight.org] *On Behalf Of *Abhijit Kumbhare > *Sent:* Wednesday, May 25, 2016 17:58 > *To:* Anil Vishnoi <vishnoia...@gmail.com> > *Cc:* openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>; > Thanh Ha <thanh...@linuxfoundation.org>; Jozef Bacigal -X (jbacigal - > PANTHEON TECHNOLOGIES at Cisco) <jbaci...@cisco.com>; > rele...@lists.opendaylight.org; Robert Varga <n...@hq.sk>; Subhash Singh < > subhash_si...@criterionnetworks.com>; nic-...@lists.opendaylight.org; > Shuva Jyoti Kar <shuva.jyoti....@ericsson.com>; > didm-...@lists.opendaylight.org; Manikantan, Anandhi < > anandhi.manikan...@hpe.com>; Michal Rehak -X (mirehak - Pantheon > Technologies SRO at Cisco) <mire...@cisco.com> > *Subject:* Re: [nic-dev] [openflowplugin-dev] [release] [didm-dev] OFP > getTableFeature() breakage in nic and didm > > > > Thanks for the good summary & analysis Anil. Having table features > collection by default on will make the performance unacceptable with OVS > 2.4 regardless of whether DIDM or NIC is being used or not. It might be > possible for people to use OpenFlow Plugin without DIDM or NIC. Hence I > think we should: > > > > 1) Disable the table features collection by default. > > 2) Provide a mechanism for DIDM/NIC to ask for the table features > on-demand via RPC (if not already present). > > 3) DIDM/NIC should use the table feature RPC to get the table features if > they need table features. > > > > Would that be acceptable to DIDM/NIC? > > > > > > > > On Wed, May 25, 2016 at 5:22 PM, Anil Vishnoi <vishnoia...@gmail.com> > wrote: > > This patch was for lithium plugin and we have a patch on the way for He > plugin as well (https://git.opendaylight.org/gerrit/#/c/39150/6). With > these both the patch, we provide uses to enable/disable the table features > in stable/beryllium branch (after SR3). > > > > In lithium plugin we disabled the table features by default and that's the > behavioural change, between SR2 and SR3, but given that it's not a default > plugin it should be fine to release note it. > > In helium plugin, table features are by default enable (in the above > patch), because DIDM and NIC project are using table features. So there is > going to be no behavioral changes as such. > > > > Looking at this bug (https://bugs.opendaylight.org/show_bug.cgi?id=5954), > table features generates 3.4 Mb of data per ovs switch and that's too huge > and it's going to significantly hit the performance of the Helium plugin, > so in my personal opinion we should disable it for He plugin as well in > stable/Beryllium branch. BUT that will impact DIDM/NIC project as well. I > can see following solutions for DIDM/NIC project to adapt this change > > > > (1) DIDM/NIC uses the table feature rpc to get the table features > > (2) They should release note that user will have to change the flag, > before starting the controller to enable the table features. > > (3) Or they can implement the code that can change the value dynamically > through data store ( i never tested this whether it works or not) once > their module initializes. > > > > DIDM/NIC will get into the same situation on their master branch, when we > will switch lithium plugin as a default plugin, given that table features > are by default disabled there. > > > > I would like to get thoughts from the people on which way we should go (1) > disable the table features by default or (2) enable and keep the existing > behavior > > > > My vote is for (1) for the reason i mentioned above. Please share you > thoughts. > > > > Thanks > > Anil > > > > On Wed, May 25, 2016 at 4:36 PM, Abhijit Kumbhare <abhijitk...@gmail.com> > wrote: > > No - but a smaller impact change ( > https://git.opendaylight.org/gerrit/#/c/36506/) to allow turning the > table features off was pushed. We had discussed at the OF Plugin meeting - > and that was the least of the evils that was decided. > > > > On Wed, May 25, 2016 at 3:21 PM, Anil Vishnoi <vishnoia...@gmail.com> > wrote: > > I don't think so this patch ( > https://git.opendaylight.org/gerrit/#/c/36559/) was pushed to stable > beryllium. > > > > On Wed, May 25, 2016 at 8:16 AM, Abhijit Kumbhare <abhijitk...@gmail.com> > wrote: > > Yes. From what I remember - the model changes were not in the last > Beryllium SR (i.e. SR 2) - so the release note of SR3 should have this. > > > > On Wed, May 25, 2016 at 1:09 AM, Robert Varga <n...@hq.sk> wrote: > > On 05/25/2016 07:43 AM, Anil Vishnoi wrote: > > So looks like these yang model changes > > Hello, > > This will need to be release-noted, as it is a change in public API. > > Bye, > Robert > > > > > > > > -- > > Thanks > > Anil > > > > > > > > -- > > Thanks > > Anil > > > -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
