#opendaylight-openflowplugin: OFP IRC meeting May 21

Meeting summary

1. 1. tbachman (tbachman, 16:18:38)
   2. https://cisco.webex.com/join/ttkacik (ttkacik, 16:20:56)
   
   
2. Decision regarding He / Li (abhijitkumbhare, 16:29:27)
   1. michal_rehak says throughput test mode has lower performance than Helium code base, but the new design has many other better properties (tbachman, 16:31:48)
   2. michal_rehak says the latency numbers are better, and statistics collection from architectural perspective look better (tbachman, 16:32:06)
   3. michal_rehak asks for arguments for going with Helium vs. Lithium (tbachman, 16:32:18)
   4. kot-begemot says the hashing codes are a big issue — thinks code shouldn’t be frozen in this state (tbachman, 16:32:36)
   5. vishnoianiol asks jamoluhrsen and LuisGomez from an integration test perspective how things look (tbachman, 16:33:12)
   6. jamoluhrsen says he doesn’t like the way it looks with the Lithium code base — too many failures (tbachman, 16:33:26)
   7. rovarga says the issue here is the version of OVS (2.0) being used in integration — has too many issues, and should be using 2.3.0+ (tbachman, 16:33:51)
   8. rovarga says the new plugin is good a flushing out the errors in OVS that weren’t detected by the old ones (tbachman, 16:34:17)
   9. my understanding is that this is related to group/meters, I think (rovarga, 16:34:38)
   10. jamoluhrsen says if that’s the case, then we need to get the CI environment updated ASAP (tbachman, 16:34:45)
   11. ttkacik says the old plugin has issues with statistics and working with groups (tbachman, 16:35:30)
   12. rovarga says there is an issue asking for an upgrade of OVS from Peter (tbachman, 16:36:00)
   13. jamoluhrsen asks if with the Helium code base, the plugin is incorrectly dealing with a broken vswitch, which is why our tests are passing (tbachman, 16:36:49)
   14. jmedved asks if jamoluhrsen can verify the behavior with the newer version of OVS (2.3) (tbachman, 16:37:19)
   15. ACTION: jamoluhrsen to verify new plugin with OVS 2.3 (tbachman, 16:37:32)
   16. kot-begemot says there is an issue between He and Li, the original match converter was flattened and unrolled. In Lithium, it’s all flat — long sequence, so patches won’t apply cleanly across both (tbachman, 16:38:25)
   17. kot-begemot says the only places where the prefixes have effect in Helium are the match conversion and action conversion; In Lithium, it also affects the hashing code. (tbachman, 16:39:08)
   18. rovarga asks if this affects IPv6 compliance, or is it a separate issue (tbachman, 16:39:20)
   19. kot-begemot says that the moment you apply the v6 conversion to Lithium, you have to fix the hashing code too (tbachman, 16:39:37)
   20. rovarga says essentially that this means the IPv6 hashing code needs to be fixed in order to correctly hash the normalized IPv6 addresses (tbachman, 16:40:18)
   21. rovarga says this seems like two interspersed problems, and instead of tackling each one individually, we’re conflating the two (tbachman, 16:41:29)
   22. kot-begemot says that with the current design of the hashing code, it’s difficult to do a fix for v6 (tbachman, 16:41:45)
   23. kot-begemot says the way it’s done currently results in a very bad hash, which creates more work and is not reusable if we fix the hashing computation (tbachman, 16:42:21)
   24. rovarga says if we take the entire hashing and just remove it, it’s not strictly required for the Lithium code base (tbachman, 16:42:55)
   25. rovarga asks if that solves the IPv6 issues (tbachman, 16:43:00)
   26. rovarga says we’re discussing two things — normalization of IPv6 and a hashing function in one of the code bases (tbachman, 16:43:18)
   27. vishnoianil says there are two separate issues, but they have overlapping boundaries (tbachman, 16:43:43)
   28. kot-begemot says it’s a side-effect of how v6 addresses are represented; once you normalize them and apply compression correctly, hash would result in the same value across a large set of them (tbachman, 16:44:17)
   29. rovarga asks if that means the code will not work correctly? (tbachman, 16:44:32)
   30. kot-begemot says hash means at least not putting everything in the same hash bucket — becomes a performance bottleneck (tbachman, 16:44:50)
   31. rovarga asks if it affects correctness or not (tbachman, 16:45:04)
   32. kot-begemot says if we take it out and don’t use it, then most of the fixes are done (tbachman, 16:45:16)
   33. rovarga asks if solving this problem allows us to cut the branch and move forward (tbachman, 16:45:44)
   34. kot-begemot says if we take out the hash code and acceleration benefit from it, what’s the difference between the Helium and Lithium branches — what’s the benefit (tbachman, 16:46:09)
   35. rovarga asks for design documents to look at to compare (tbachman, 16:46:22)
   36. https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Lithium_Design_Proposal (michal_rehak, 16:46:36)
   37. rovarga says if you look at the design differences, the benefits should be self-evident (tbachman, 16:46:43)
   38. https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Lithium_Design_Proposal Link to design of new openflowplugin for Lithium (tbachman, 16:47:14)
   39. kot-begemot says he read something about changing the way the I/O works — wants to understand what has changed (tbachman, 16:47:50)
   40. https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Lithium_Release_Plan (colindixon, 16:48:02)
   41. https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Lithium_Release_Plan The OpenFlow plugin Lithium release plan, with link to redesign (tbachman, 16:50:42)
   42. colindixon asks if we can make it so that users can pick which OF plugin implementation they can use (tbachman, 16:50:55)
   43. rovarga says it’s already that way — there are two features (tbachman, 16:51:06)
   44. rovarga asks what’s blocking us from creating the branch (tbachman, 16:51:39)
   45. vishnoianil thinks the main reason was the IPv6 was the main thing blocking the branch (tbachman, 16:51:53)
   46. rovarga asks who owns the IPv6 issue (tbachman, 16:52:00)
   47. kot-begemot says that in the current state, the Lithium gerit will fix everything but the hashing code (tbachman, 16:52:16)
   48. rovarga asks if we take out the hashing code with those fixes, then we’re good to cut the branch (tbachman, 16:52:47)
   49. https://git.opendaylight.org/gerrit/#/c/20704 Lithium gerritt (abhijitkumbhare, 16:53:02)
   50. kot-begemot says taking it out and fixing it is not suitable to be done for freezing (tbachman, 16:53:04)
   51. kot-begemot says we still have this failing in CI — from a code perspective, the answer is yes (tbachman, 16:53:21)
   52. jmedved asks how we can solve the problem of cutting the branch (tbachman, 16:57:11)
   53. rovarga says we can also take this decision to the TSC (tbachman, 16:57:53)
   54. kot-begemot says the key question is to be whether we should use the Helium or Lithium plugin (tbachman, 16:59:11)
   55. rovarga says colindixon pointed out that we can ship both and let users decide (currently both features are there) (tbachman, 16:59:30)
   56. rovarga says what we need to solve is the problem of the stable/lithium branch (tbachman, 16:59:45)
   57. vishnoianil says he votes for that approach (two features) (tbachman, 16:59:57)
   58. abhijitkumbhare asks if we’re okay with two implementations or single implementnation (tbachman, 17:00:09)
   59. abhijitkumbhare says it sounds like most folks are okay with both implementations (tbachman, 17:00:24)
   60. abhijitkumbhare asks if anyone is opposed to both implementations (tbachman, 17:00:35)
   61. vishnoianil says he approves, with the default being the Helium plugin (tbachman, 17:00:50)
   62. abhijitkumbhare says we can make the call as to which is the default at RC0, 1, 2.... (tbachman, 17:01:15)
   63. kot-begemot says he’s fine with that — as long as users have a stable version to work with, he’s fine with that (tbachman, 17:01:34)
   64. AGREED: : openflowplugin to provide both Helium and Lithium implementations as part of the Lithium release (tbachman, 17:01:57)
   65. VOTE: Voted on "Should the committers decide to cut stable/lithium?" Results are, +1: 4 (tbachman, 17:05:01)
   66. My vote is +1, we should go ahead with branch cutting given that Ipv?prefix issue is fixed in He code base (vishnoianil, 17:05:57)
   67. we will take on more call on Rc0 about the concerns discussion by the members, on switching to new Li implementaiton (vishnoianil, 17:06:48)
   68. we will still stick to both the implementations (Helium default and Lithium) (tbachman, 17:06:51)
   69. kot-begemot says he will fix it in the Lithium code base without the hashing code (tbachman, 17:07:07)
   70. if we will not be able to take clear decision on that, we can ship both the implementation in LI release and defer it to User to use either of the feature (vishnoianil, 17:07:25)
   71. that part is broken as it is now, and needs a rewrite to be a hash. Presently it is not. Adding all values in header fields a hash does not make (kot-begemot, 17:08:24)
   72. AGREED: we should go ahead with branch cutting given that Ipv?prefix issue is fixed in He code base (abhijitkumbhare, 17:09:49)
   73. AGREED: we will still stick to both the implementation (He (default) and Li) (abhijitkumbhare, 17:10:03)
   74. AGREED: we will take on more call on Rc0 about the concerns discussion by the members, on switching to new Li implementaiton (abhijitkumbhare, 17:10:22)
   75. AGREED: if we will not be able to take clear decision on that, we can ship both the implementation in LI release and defer it to User to use either of the feature (abhijitkumbhare, 17:10:39)

Action items

1. jamoluhrsen to verify new plugin with OVS 2.3

Action items, by person

1. jamoluhrsen
   1. jamoluhrsen to verify new plugin with OVS 2.3

People present (lines said)

1. tbachman (88)
2. abhijitkumbhare (26)
3. colindixon (14)
4. odl_meetbot (13)
5. kot-begemot (9)
6. ttkacik (4)
7. vishnoianil (4)
8. michal_rehak (2)
9. rovarga (2)
10. v_demcak (1)
11. mbobak (1)
12. jamoluhrsen (1)