+1 for disabling table features by default as this has performance impact and is also consistent with the lithium plugin.
From: openflowplugin-dev-boun...@lists.opendaylight.org [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Anil Vishnoi Sent: 26 May 2016 05:52 To: Abhijit Kumbhare Cc: openflowplugin-dev; Thanh Ha; rele...@lists.opendaylight.org; Robert Varga; Subhash Singh; nic-...@lists.opendaylight.org; didm-...@lists.opendaylight.org Subject: Re: [openflowplugin-dev] [nic-dev] [release] [didm-dev] OFP getTableFeature() breakage in nic and didm 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<mailto: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<mailto: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<mailto: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<mailto: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
_______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
