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<mailto: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<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
