On 2024/09/27 19:18:03 Rajan Dhabalia wrote: > Well, again PR#9292 already has an agreement to merge earlier as well and > it was reviewed as well but it just was blocked for no reason. and recently > it was acknowledged that PR#9292 fulfills the purpose of most of the > usecases and we should move forward with the approach. and that was the > reason, I had again spent time rebasing as rebasing efforts were already > mentioned in another thread and therefore we made it ready to make sure we > can use this feature for most of the usecases. I don't see any concern and > issue to not move forward now with PR#9292 unless if anyone comes with a > personal reason. PR#9292 is straightforward and it would be great if > reviewers can review it again and we can make progress to make this feature > available soon.
I'm late to reviewing PR 9292, and I reviewed it after it was merged. The change in the merged PR 9292 is very useful if I understand it correctly. Thanks for the great work, Rajan. Since individual acknowledgments get encoded as a long[] array, it will compress the information significantly. A single long entry in the array will hold 64 bits and therefore 64 individual acknowledgments. In theory, 1 million (1024 * 1024) individual bits can be held in 128kB of memory (1024kB / 8) since every bit will encode one acknowledgment. Is this the correct understanding of how PR 9292 efficiently stores individual acks? -Lari
