I thought the fix on the master is not changing the default behavior. If it
is, then regardless of which approach we take we will have a different
behavior. Hence we will need to release note in either case.

On Wed, May 11, 2016 at 9:46 AM, Luis Gomez <[email protected]> wrote:

> Default behavior an small API change as far as I remember, that is why we
> decide to do it in master only.
>
> On May 11, 2016, at 12:50 AM, Jozef Bacigal -X (jbacigal - PANTHEON
> TECHNOLOGIES at Cisco) <[email protected]> wrote:
>
> Yes we have fix on master, but I think we all agreed put this fix only on
> master because it change the default behavior.
>
> Jozef
>
> *From:* Abhijit Kumbhare [mailto:[email protected]
> <[email protected]>]
> *Sent:* 11. mája 2016 8:33
> *To:* Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco) <
> [email protected]>
> *Cc:* Anil Vishnoi <[email protected]>; [email protected];
> Abhijit Kumbhare <[email protected]>; Subhash Singh <
> [email protected]>; Luis Gomez Palacios <
> [email protected]>; [email protected]
> *Subject:* Re: [openflowplugin-dev] table features
>
> The next SR is July end - and I believe you will have the actual fix in
> the master & not a workaround - right? If that is the case - then can that
> be ported to stable/beryllium before the next SR?
>
> On Tue, May 10, 2016 at 11:01 PM, Jozef Bacigal -X (jbacigal - PANTHEON
> TECHNOLOGIES at Cisco) <[email protected]> wrote:
>
> Abhijit hard to decide but if we declare some performance in SR2 we should *if
> possible* put it in this release. And the pull from master you mean the
> actual fix yang model structure change not this "workaround" ?
>
>
>
> Jozef
> ------------------------------
> *From:* Abhijit Kumbhare <[email protected]>
> *Sent:* Tuesday, May 10, 2016 5:32 PM
> *To:* Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco)
> *Cc:* Anil Vishnoi; [email protected]; Abhijit Kumbhare; Subhash
> Singh; Luis Gomez Palacios; [email protected]
>
> *Subject:* Re: [openflowplugin-dev] table features
>
> Jozef,
>
> On a second glance - the patch is not merged. So we will not need to add
> it to the SR2 release notes (the build done on Friday). So can you please
> update your patch to have the following description so we will not forget
> when it is time to actually release note?
>
> Added the ability to configure whether to pull table features for the Li
> design and changed the default to skip pulling table features for the
> feature.
> Data yang model defines a table features inside of table grouping. OVS 2.4
> finally supports table features. Now large table features data are stored
> inside of each table. It means 254 table features are stored in DS. This
> ability allows skip pulling and storing of large table features. Table
> features are still available via rpc but if set to true then maintenance in
> DS will be omitted and DS latency for inventory will be the same as by OVS
> >=2.3.
>
> Secondly - if the table features performance fix is already available &
> since the next SR is a few months away - do you think it would be better to
> just pull the actual fix from master once we know there are no side effects?
>
> Thanks,
> Abhijit
>
> On Tue, May 10, 2016 at 7:22 AM, Abhijit Kumbhare <[email protected]>
> wrote:
>
> Thanks Jozef! Good explanation - I will work with An later today to get it
> into the release notes.
>
> On Tue, May 10, 2016 at 4:05 AM, Jozef Bacigal -X (jbacigal - PANTHEON
> TECHNOLOGIES at Cisco) <[email protected]> wrote:
>
> Data yang model defines a table features inside of table grouping. OVS 2.4
> finally supports table features. Now large table features data are stored
> inside of each table. It means 254 table features are stored in DS. This
> ability allow skip pulling and storing of large table features. Table
> features are still available via rpc but if set to true then maintenance in
> DS will be omitted and DS latency for inventory will be the same as by OVS
> >=2.3.
>
>
> ------------------------------
> *From:* Anil Vishnoi <[email protected]>
> *Sent:* Tuesday, May 10, 2016 9:44 AM
>
> *To:* Abhijit Kumbhare
> *Cc:* Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco);
> [email protected]; Abhijit Kumbhare; Subhash Singh;
> [email protected]; Luis Gomez Palacios
> *Subject:* Re: [openflowplugin-dev] table features
>
>
>
> On Tue, May 10, 2016 at 12:30 AM, Abhijit Kumbhare <[email protected]>
> wrote:
>
> This change was due to the major performance hit on OVS 2.4 - and I
> believe was a decision at one of the meetings. Reason: the inefficient
> table features fetch were always causing a significant performance drop
> regardless of whether DIDM or any other features needing table features
> were enabled or not. If I remember right - the decision was to turn off the
> table features on stable/beryllium & add the riskier fix on the master
> first & then maybe port it to the stable/beryllium after some time it has
> been baked in (may be in the next SR).
>
> So it would be better to release note it I think.
>
> ​Yes, so lets do it.​
>
>
>
> Do you have a short 3-4 line description Jozef for release note
> (explaining why it was changed)?
>
> On Tue, May 10, 2016 at 12:22 AM, Anil Vishnoi <[email protected]>
> wrote:
>
> Personally i want it to be disabled by default, but if i look at it from
> user perspective, we are changing the behaviour between two SR version and
> it might be of some concern. But if this change is for lithium plugin, i
> think the impact is minimal, so i think if we can release note it, that
> would be better.
>
> On Mon, May 9, 2016 at 11:32 PM, Jozef Bacigal -X (jbacigal - PANTHEON
> TECHNOLOGIES at Cisco) <[email protected]> wrote:
>
> You propose to leave the flag (skip table features) false ? Just not to
> change default behavior?
>
>
>
> Jozef
> ------------------------------
> *From:* Anil Vishnoi <[email protected]>
> *Sent:* Monday, May 9, 2016 7:21 PM
> *To:* Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco)
> *Cc:* Abhijit Kumbhare; [email protected]; Abhijit Kumbhare; Subhash
> Singh; [email protected]; Luis Gomez Palacios
>
> *Subject:* Re: [openflowplugin-dev] table features
>
> okay, although it's been done for li plugin, but i think it will change
> the default behavior between two SR (SR2 and SR-3).
>
> On Mon, May 9, 2016 at 1:48 AM, Jozef Bacigal -X (jbacigal - PANTHEON
> TECHNOLOGIES at Cisco) <[email protected]> wrote:
>
> Nope, in stable/beryllium we add just this on/off flag, with default
> setting on OFF table features.
>
>
>
> https://git.opendaylight.org/gerrit/#/c/36506/3
>
>
>
> Jozef
> ------------------------------
> *From:* Anil Vishnoi <[email protected]>
> *Sent:* Monday, May 9, 2016 10:37 AM
> *To:* Abhijit Kumbhare
> *Cc:* Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco);
> [email protected]; Abhijit Kumbhare; Subhash Singh;
> [email protected]; Luis Gomez Palacios
>
> *Subject:* Re: [openflowplugin-dev] table features
>
> was this patch merged to stable/beryllium as well?
>
> On Tue, Apr 26, 2016 at 8:21 AM, Abhijit Kumbhare <[email protected]>
> wrote:
>
> OK.
>
> On Tue, Apr 26, 2016 at 12:18 AM, Jozef Bacigal -X (jbacigal - PANTHEON
> TECHNOLOGIES at Cisco) <[email protected]> wrote:
>
> Hi Abhijit,
>
>
>
> I thought I get an answer from NIC and DIDM guys, but in this case, I
> would propose we just make the on/off flag in beryllium SR3 and this
> solution we merge only into master M3 as we agreed with Luiz.
>
>
>
> Jozef
> ------------------------------
> *From:* Abhijit Kumbhare <[email protected]>
> *Sent:* Monday, April 25, 2016 9:20 PM
> *To:* Subhash Singh
> *Cc:* Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco);
> Abhijit Kumbhare;[email protected];
> [email protected]
> *Subject:* Re: [openflowplugin-dev] table features
>
> Hi Jozef,
>
> Will you be putting https://git.opendaylight.org/gerrit/#/c/36559 into
> stable/beryllium after sometime has passed or do you think its better to
> avoid it altogether in stable/beryllium?
>
> Thanks,
> Abhijit
>
> On Mon, Apr 25, 2016 at 5:33 AM, Subhash Singh <
> [email protected]> wrote:
>
> +[Anandhi]
>
> --
> Regards,
> Subhash Kumar Singh
>
> On Mon, Apr 25, 2016 at 2:42 PM, Jozef Bacigal -X (jbacigal - PANTHEON
> TECHNOLOGIES at Cisco) <[email protected]> wrote:
>
> Hi everyone, mainly guys from NIC and DIDM,
>
> I would ask you if you can read and talk about the bug 5464 table features
>
> https://bugs.opendaylight.org/show_bug.cgi?id=5464
>
> There are two proposals, first (berylium SR2) that we merge the skip flag,
> which is I would say some "workaround" and set the flag to TRUE so we
> default skip the table features
>
> https://git.opendaylight.org/gerrit/#/c/36506/
>
> and second (boron M3)  this solution of the problem which would lead to
> changes into your projects
>
> https://git.opendaylight.org/gerrit/#/c/36559
>
> We would much appreciate you answers
>
> Jozef
>
>
>
>
> _______________________________________________
> openflowplugin-dev mailing list
> [email protected]
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
>
>
>
>
>
>
> _______________________________________________
> openflowplugin-dev mailing list
> [email protected]
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
>
>
>
>
> --
> Thanks
> Anil
>
>
>
>
> --
> Thanks
> Anil
>
>
>
>
> --
> Thanks
> Anil
>
>
>
>
>
>
> --
> Thanks
> Anil
>
>
>
_______________________________________________
openflowplugin-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Reply via email to