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]] 
> 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] <mailto:[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] <mailto:[email protected]>>
> Sent: Tuesday, May 10, 2016 5:32 PM
> To: Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco)
> Cc: Anil Vishnoi; [email protected] <mailto:[email protected]>; 
> Abhijit Kumbhare; Subhash Singh; Luis Gomez Palacios; 
> [email protected] 
> <mailto:[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] 
> <mailto:[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] <mailto:[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] <mailto:[email protected]>>
> Sent: Tuesday, May 10, 2016 9:44 AM 
> 
> To: Abhijit Kumbhare
> Cc: Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco); 
> [email protected] <mailto:[email protected]>; Abhijit Kumbhare; 
> Subhash Singh; [email protected] 
> <mailto:[email protected]>; Luis Gomez Palacios
> Subject: Re: [openflowplugin-dev] table features
>  
>  
>  
> On Tue, May 10, 2016 at 12:30 AM, Abhijit Kumbhare <[email protected] 
> <mailto:[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] 
> <mailto:[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] <mailto:[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] <mailto:[email protected]>>
> Sent: Monday, May 9, 2016 7:21 PM
> To: Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco)
> Cc: Abhijit Kumbhare; [email protected] <mailto:[email protected]>; 
> Abhijit Kumbhare; Subhash Singh; [email protected] 
> <mailto:[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] <mailto:[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 
> <https://git.opendaylight.org/gerrit/#/c/36506/3>
>  
> 
> Jozef
> 
> From: Anil Vishnoi <[email protected] <mailto:[email protected]>>
> Sent: Monday, May 9, 2016 10:37 AM
> To: Abhijit Kumbhare
> Cc: Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco); 
> [email protected] <mailto:[email protected]>; Abhijit Kumbhare; 
> Subhash Singh; [email protected] 
> <mailto:[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] 
> <mailto:[email protected]>> wrote:
> OK.
>  
> On Tue, Apr 26, 2016 at 12:18 AM, Jozef Bacigal -X (jbacigal - PANTHEON 
> TECHNOLOGIES at Cisco) <[email protected] <mailto:[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] <mailto:[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] <mailto:[email protected]>; 
> [email protected] 
> <mailto:[email protected]>
> Subject: Re: [openflowplugin-dev] table features
>  
> Hi Jozef,
>  
> Will you be putting https://git.opendaylight.org/gerrit/#/c/36559 
> <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] 
> <mailto:[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] <mailto:[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 
> <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/ 
> <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 
> <https://git.opendaylight.org/gerrit/#/c/36559>
>  
> We would much appreciate you answers
> 
> Jozef
> 
> 
>  
> 
> _______________________________________________
> openflowplugin-dev mailing list
> [email protected] 
> <mailto:[email protected]>
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
> <https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev>
>  
>  
> 
> _______________________________________________
> openflowplugin-dev mailing list
> [email protected] 
> <mailto:[email protected]>
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
> <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