Is memory chunk size limit < 4GB?

[kozakusek]

When trying to start RouDi with a 4GB segment.mempool I encountered an unpleasant error:

 Condition: (t >= Minimum) && (t <= Maximum) in iox::range<T, Minimum, Maximum>::range(T) [with T = unsigned int; T Minimum = 1; T Maximum = 4294967255] is violated. (/workdir/iceoryx/iceoryx_hoofs/primitives/include/iox/algorithm.hpp:208)

Then after reading into the source code I noticed that in many cases (e.g. iox_pub_loan_chunk) the variable that refers to size is of type uint32_t.

Is there a reason for this limitation? Are you planning to add support for bigger memory chunks by adding option to hold size in 64bit integers?

Thanks

[elfenpiff]

@kozakusek You are right this is an unpleasant and I think also technical unnecessary restriction.

We never encountered a use case where we required more than 4GB so we never paid attention to this restriction, but we most certainly can lift this (with the little constraint that there is maybe an unlikely restriction that this would cause a bigger refactoring).

Is this something that blocks you right now? And would you be free to explain roughly your use case so that we also learn something new we did not yet have on our radar.

[elBoberido]

@kozakusek I think the 4GB limit has mostly historical reasons. It shouldn't be too hard to implement but we are currently quite busy with other stuff. How critical is this for you in terms of time?

[elBoberido]

Oh, and what @gpalmer-latai said is also to consider. The memory is managed by a bucket allocator and depending on how many of the 75GB chunks you need you might waste quite a lot of memory. If you have a clear and deterministic chain, you might get away with one chunk though.

[kozakusek]

Thank you @gpalmer-latai for pointing me to the MemPool file.
Starting from there I did some code traversal tweaking the types and it looks like it can work!
(Unlike number of chunks it doesn't seem like it is used in any bit tricks.)
At least I managed to run iceperf_bench using bigger chunks.

Therefore I have another question, what is the chance of you accepting the changes upstream (after I clean this up a bit and make a PR)?
And if it is possible, how often do you publish patches, so it can be officially available?

[elBoberido]

@kozakusek the chances are quite high. We welcome and appreciate patches. There is a formality to get used to in the beginning but nothing wild.

• you need so sign the ECA
• every PR must have a corresponding issue
• ideally the branch for the PR should start with iox-issue_number, e.g. iox-42-large-chunk-support
• commits need to be prefixed with iox-#issue_number, e.g. iox-#42 Allow chunks larger than 4GB
  All of this is described in CONTRIBUTING.md and if you use the commit hooks from tools/git-hooks some to the checks are done while committing.

Looking forward to the PR :)

[elBoberido]

Regarding the release. We plan to release soonish and then have a shorter release cycle than what we had till now. I think a release every 3-4 month might work. If there is demand we could release even more often.

There is also a developer meetup on Tuesday 5pm CET. It is once a month, usually the first Tuesday but due to the vacation time we shifted it to the second Tuesday. There is also a special meeting on January 16th to introduce the Rust based iceroyx2.

[gpalmer-latai]

FWIW I've had no issue configuring a memory pool to support more than 4GB. I did uncover a bug in the process, but the bug was fixed and everything should work now.

And it looks like this isn't exactly your issue. I surmise the maximum value comes from here: https://github.com/eclipse-iceoryx/iceoryx/blob/master/iceoryx_posh/include/iceoryx_posh/internal/mepoo/memory_manager.hpp#L49

The reason you encounter the failure is not that the memory pool is greater than 4GB, but because the chunk payload size is greater than 4GB (minus some chunk header overhead).

So the question is what would need to be done to support chunk sizes greater than 4GB, and perhaps increase this size limit to numeric_limits<uint64_t>::max?