iox-1803 Expand cmake configuration options #1804

JakubSosnovec · 2022-11-25T09:45:32Z

Pre-Review Checklist for the PR Author

Notes for Reviewer

Based on this discussion: #1770

Checklist for the PR Reviewer

Commits are properly organized and messages are according to the guideline
Code according to our coding style and naming conventions
Unit tests have been written for new behavior
Public API changes are documented via doxygen
Copyright owner are updated in the changed files
All touched (C/C++) source code files from iceoryx_hoofs have been added to ./clang-tidy-diff-scans.txt
PR title describes the changes

Post-review Checklist for the PR Author

All open points are addressed and tracked via issues

References

Closes Increase configurability to allow smaller memory consumption #1803

elfenpiff

@JakubSosnovec I have no other words than: This is awesome!

Thank you so much for this great work we truly appreciate this!

elfenpiff

You need to add the small_memory example as an exception to tools/iceoryx_build_test.sh (line 318 ff) since it does not contain any actual source code.

JakubSosnovec · 2022-11-25T10:10:08Z

@elfenpiff @elBoberido There are a few things to get your opinion on:

Is the small_memory example a proper way how to demonstrate this? It isnt really an example since it doesnt have any source, it is rather a guide on how to achieve small memory footprint while keeping the basic helloworld demo functional. It could be another documentation guide. Not sure.
I picked the variables that showed the most influence on memory usage. However, this leaves some constants still not configurable, because they dont influence memory so much. Now, it might sometimes be a bit strange, for example MAX_RESPONSES_PROCESSED_SIMULTANEOUSLY , MAX_RESPONSE_QUEUE_CAPACITY and MAX_REQUEST_QUEUE_CAPACITY are configurable with cmake, but MAX_REQUESTS_ALLOCATED_SIMULTANEOUSLY is still hard-coded. Should we be consistent and make all the options configurable, or just keep it like this for now?

codecov · 2022-11-25T10:13:51Z

Codecov Report

Merging #1804 (ce3dddd) into master (754e13d) will decrease coverage by 0.06%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1804      +/-   ##
==========================================
- Coverage   75.53%   75.48%   -0.06%     
==========================================
  Files         375      375              
  Lines       14594    14596       +2     
  Branches     2070     2071       +1     
==========================================
- Hits        11024    11018       -6     
- Misses       2941     2949       +8     
  Partials      629      629

Flag	Coverage Δ
unittests	`75.15% <100.00%> (-0.06%)`	⬇️
unittests_timing	`15.29% <0.00%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...ofs/include/iceoryx_hoofs/internal/cxx/convert.inl	`82.60% <100.00%> (+0.21%)`	⬆️
iceoryx_hoofs/source/concurrent/loffli.cpp	`80.00% <0.00%> (-5.72%)`	⬇️
iceoryx_posh/source/roudi/port_manager.cpp	`84.05% <0.00%> (-1.13%)`	⬇️

budrus · 2022-11-25T16:01:19Z

iceoryx_examples/small_memory/README.md

+
+Please note that it might be impossible to build some other iceoryx examples,
+since the decreased maximum length of service and runtime name strings might
+cause some static assertion failures. This problem demonstrates that the user


@JakubSosnovec These assertions are because the strings used in the other examples are too long then? Would it make sense to ensure all examples are compatible with the small_memory setup? Compiling maybe would be possible but we would get runtime problem as the resource limits are too small, I guess. So if we would like to ensure that all examples work, this would lead to bad compromises, e.g. having to increase the numbers again a bit because mempools are too small or not enough subscribers are possible. What do you think?

Yes, some examples will fail to even compile, because iox::cxx::string constructors have static asserts for checking the length of string literals passed in -- and some demos have quite long strings for either runtime names or service description names.
Furthermore, even if we get through compilation, the memory pool in this demo is extremely small (10x512b), so I expect that wouldnt be enough for some other demos.
Of course, we could increase the resource limits, but then the demo memory usage wouldnt fit into 100 kB. So I thought it is better to keep it as is, and add a warning that decreasing the resource limits of course has some consequences, such as incompatibility with demos other than the hello world example.
Is that okey with you?

@JakubSosnovec Yes, I wouldn't make bad compromises that increase the memory footprint again. If we have the disclaimer then it is also OK if we get runtime errors when executing other examples that need larger mempools, more subscribers etc. The only question for me would then be the compile time one. I.e. should we maybe change the runtime and service ID names of the other examples to be compatible with your setup. I think you have max string length of 30 from what I saw which should be manageable.

Pinging @elfenpiff as he already reviewed to see what he thinks

@budrus I do not think it is a good idea to adapt all examples to minimal configuration. Runtime errors are OK, if stated that only specific examples work with the minimal configuration.

From the perspective of compile time, as already mentioned the maximum string length is the main reason why a build can fail. This is a side effect of the way the static strings work, there has to be a limit (in the static case) and failing early (e.g. already at compilation) is preferable.

String sizes affect service description sizes, which affect port sizes etc. which contribute significantly to the memory footprint of the management segment, so there is a trade-off.

Maybe it is worth considering to have a minimal with minimal string size that builds only one example?

Tests might still be a problem, as they also use strings and may also need to excluded from the build for a minimal configuration. String size should probably be a power of two, to reduce wasted memory due to alignment in some cases, say 32.

There is no simple answer here to make everything work with really low string sizes.

Luckily the user memory segment has less issues and is fairly flexible regarding its size. It still reminds me that the internal allocation is wasteful and fairly inflexible though (to be changed when we provide advanced allocator support).

@MatthiasKillat

Maybe it is worth considering to have a minimal with minimal string size that builds only one example?

Thats exactly what I did. The small_memory example that I added is basically just a guide on how to configure iceoryx just enough to be able to build the icehello example. I do know that other examples will fail, since some of them use very long strings.

iceoryx_posh/BUILD.bazel

elBoberido · 2022-12-01T22:18:04Z

@JakubSosnovec I can just repeat what elfenpiff said. Thanks very much for the PR. Unfortunately I did not yet have time to do a review but it's at the top of my todo list for next week :)

MatthiasKillat

Looks good and makes some previously non-configurable options configurable now. I did not try to build and run it yet, will do so on Monday. If we can solve the (potential) build issue with potential problems due to reduced string length we can merge it IMO.

@JakubSosnovec

MatthiasKillat · 2022-12-09T15:25:18Z

iceoryx_examples/small_memory/README.md

+
+Please note that it might be impossible to build some other iceoryx examples,
+since the decreased maximum length of service and runtime name strings might
+cause some static assertion failures. This problem demonstrates that the user


@budrus I do not think it is a good idea to adapt all examples to minimal configuration. Runtime errors are OK, if stated that only specific examples work with the minimal configuration.

From the perspective of compile time, as already mentioned the maximum string length is the main reason why a build can fail. This is a side effect of the way the static strings work, there has to be a limit (in the static case) and failing early (e.g. already at compilation) is preferable.

String sizes affect service description sizes, which affect port sizes etc. which contribute significantly to the memory footprint of the management segment, so there is a trade-off.

Maybe it is worth considering to have a minimal with minimal string size that builds only one example?

Tests might still be a problem, as they also use strings and may also need to excluded from the build for a minimal configuration. String size should probably be a power of two, to reduce wasted memory due to alignment in some cases, say 32.

There is no simple answer here to make everything work with really low string sizes.

Luckily the user memory segment has less issues and is fairly flexible regarding its size. It still reminds me that the internal allocation is wasteful and fairly inflexible though (to be changed when we provide advanced allocator support).

MatthiasKillat · 2022-12-09T15:37:05Z

iceoryx_examples/small_memory/options.cmake

+set(IOX_MAX_SHM_SEGMENTS 2 CACHE STRING "")
+set(IOX_MAX_NUMBER_OF_MEMPOOLS 3 CACHE STRING "")
+set(IOX_MAX_NUMBER_OF_CONDITION_VARIABLES 8 CACHE STRING "")
+set(IOX_MAX_NODE_NAME_LENGTH 30 CACHE STRING "")


Could maybe be like 32 and still not use much more memory due to alignment. But likely will use a little more, so there is a difference.

@MatthiasKillat 32 would lead to 7 wasted bytes due to the string capacity being length + 1. What would work would be 31 but that looks ugly and I think keeping it at 30 is a good aesthetic compromise.

MatthiasKillat · 2022-12-09T15:40:33Z

iceoryx_examples/small_memory/roudi_config.toml

+[[segment]]
+
+[[segment.mempool]]
+size = 512


Maybe the size can be reduced even more (like 256), depending on the needs of the example. For count I am also a big fan of powers of two (8 or 16 maybe?) but of course it is not mandatory.

Overall the data segment organization memory consumption is fairly easy to change, unlike the management memory consumption.

Exactly, it is a runtime option, not a compile time one.

MatthiasKillat · 2022-12-09T15:43:23Z

iceoryx_hoofs/include/iceoryx_hoofs/internal/cxx/convert.inl

-/// @NOLINTBEGIN(cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers)
-template <>
-inline bool convert::fromString<string<100>>(const char* v, string<100>& dest) noexcept
+template <uint64_t Capacity>


Good catch. Why was there a leftover magic number specialization in the first place... :-)

*cough* CString100 *cough*

iceoryx_posh/BUILD.bazel

MatthiasKillat · 2022-12-09T16:28:21Z

iceoryx_posh/cmake/IceoryxPoshDeployment.cmake

-    set(IOX_MAX_CHUNKS_HELD_PER_SUBSCRIBER_SIMULTANEOUSLY 256)
-endif()
-message(STATUS "[i] IOX_MAX_CHUNKS_HELD_PER_SUBSCRIBER_SIMULTANEOUSLY:" ${IOX_MAX_CHUNKS_HELD_PER_SUBSCRIBER_SIMULTANEOUSLY})
+configure_option(


OK, we keep the defaults from before here, right?

Yes, these values are the defaults that were hard-coded before.

iceoryx_posh/BUILD.bazel

MatthiasKillat · 2022-12-09T16:35:36Z

iceoryx_posh/cmake/iceoryx_posh_deployment.hpp.in

@@ -46,6 +47,21 @@ constexpr uint64_t IOX_MAX_PUBLISHER_HISTORY = static_cast<uint32_t>(@IOX_MAX_PU
 constexpr uint32_t IOX_MAX_CHUNKS_HELD_PER_SUBSCRIBER_SIMULTANEOUSLY =
    static_cast<uint32_t>(@IOX_MAX_CHUNKS_HELD_PER_SUBSCRIBER_SIMULTANEOUSLY@);
 constexpr uint32_t IOX_MAX_NUMBER_OF_NOTIFIERS = static_cast<uint32_t>(@IOX_INTERNAL_MAX_NUMBER_OF_NOTIFIERS@);
+ constexpr uint32_t IOX_MAX_PROCESS_NUMBER = static_cast<uint32_t>(@IOX_MAX_PROCESS_NUMBER@);


Correct me if I am wrong, but these appear all to be new options according to the diff. But I was sure we e.g. already had some of these for say request-response in sme way (e.g. IOX_MAX_CLIENTS_PER_SERVER).

Can you confirm that these are new parameters?

Edit: Answered myself (I think) but still leave the comment for confirmation.

MatthiasKillat · 2022-12-09T16:38:56Z

iceoryx_posh/include/iceoryx_posh/iceoryx_posh_types.hpp

@@ -86,20 +86,20 @@ constexpr uint32_t MAX_GATEWAY_SERVICES = 2 * MAX_CHANNEL_NUMBER;
 // Client
 constexpr uint32_t MAX_CLIENTS = build::IOX_MAX_SUBSCRIBERS;
 constexpr uint32_t MAX_REQUESTS_ALLOCATED_SIMULTANEOUSLY = 4U;
-constexpr uint32_t MAX_RESPONSES_PROCESSED_SIMULTANEOUSLY = 16U;
-constexpr uint32_t MAX_RESPONSE_QUEUE_CAPACITY = 16U;
+constexpr uint32_t MAX_RESPONSES_PROCESSED_SIMULTANEOUSLY = build::IOX_MAX_RESPONSES_PROCESSED_SIMULTANEOUSLY;


Ah yes, I can answer my own question now. We had the options but they were hard-coded here.

However, it is somewhat inconsistent as some of them are still hard-coded. No need for changes, just an observation. We do not want some of them configurable, but the distinction may look arbitrary and not cleanly separated. Something for another issue, maybe.

Absolutely, I was also unsure about this inconsistency here . We can easily add at least the obvious ones, such as MAX_REQUESTS_PROCESSED_SIMULTANEOUSLY. It would make sense to me, I guess.

MatthiasKillat · 2022-12-09T16:45:32Z

iceoryx_hoofs/include/iceoryx_hoofs/cxx/convert.hpp

+    /// @param[in] dest destination to which the value should be written
+    /// @return false = if the conversion fails otherwise true
+    template <uint64_t Capacity>
+    static bool fromString(const char* v, string<Capacity>& dest) noexcept;


Is this tested? Maybe indirectly by passing a string<Capacity> to the previously existing template but then why do we need this overload in the first place?

If it is not tested we should add at least three tests, one with an empty string, one with a non-empty one and one with maximum length Capacity.

MatthiasKillat · 2022-12-09T16:51:59Z

iceoryx_hoofs/include/iceoryx_hoofs/internal/cxx/convert.inl

-template <>
-inline bool convert::fromString<string<100>>(const char* v, string<100>& dest) noexcept
+template <uint64_t Capacity>
+inline bool convert::fromString(const char* v, string<Capacity>& dest) noexcept


I see now why we would need to add this overload. So in theory it should be tested in the way I requested with a string<100>. Did not check, but nothing breaks in the CI so it works or is untested.

I added a simple test for convert::fromString overload. Also I actually modified the implementation to return false if the source size exceeds the cxx::string capacity.

dkroenke · 2022-12-14T18:13:49Z

iceoryx_examples/small_memory/README.md

@@ -0,0 +1,76 @@
+# icehello with minimal memory usage


Checked the example and it worked well thanks to the good description. Will continue reviewing.

@JakubSosnovec To make this example visible on the website you can add a simple redirection with a title in https://github.com/eclipse-iceoryx/iceoryx/tree/master/doc/website/examples to link to this markdown file.
Additionally please add an entry in https://github.com/eclipse-iceoryx/iceoryx/blob/master/doc/website/examples/.pages

Output looks like this: https://iceoryx.io/v2.0.2/examples/

What to do if a new example is created is also documented here.

@dkroenke @mossmaurice I have now added the example documentation and links according to https://github.com/eclipse-iceoryx/iceoryx/blob/master/CONTRIBUTING.md#how-to-add-a-new-example, including the asciinema recording (seding the user to hypnotoad screwed up the recording a bit, because of the different lengths of my username and hypnotoad, so I used htoad instead).

Please take a look :)

JakubSosnovec · 2023-01-02T10:51:34Z

I have rebased to latest master, to fix some merge conflicts in copyright comment lines.

elBoberido

Note to myself: Don't give estimates for PR reviews 😅

Looks good. Could be merged from my point of view.

elBoberido · 2023-01-12T21:32:17Z

iceoryx_examples/small_memory/options.cmake

+set(IOX_MAX_SHM_SEGMENTS 2 CACHE STRING "")
+set(IOX_MAX_NUMBER_OF_MEMPOOLS 3 CACHE STRING "")
+set(IOX_MAX_NUMBER_OF_CONDITION_VARIABLES 8 CACHE STRING "")
+set(IOX_MAX_NODE_NAME_LENGTH 30 CACHE STRING "")


@MatthiasKillat 32 would lead to 7 wasted bytes due to the string capacity being length + 1. What would work would be 31 but that looks ugly and I think keeping it at 30 is a good aesthetic compromise.

elBoberido · 2023-01-12T21:33:13Z

iceoryx_examples/small_memory/roudi_config.toml

+[[segment]]
+
+[[segment.mempool]]
+size = 512


Exactly, it is a runtime option, not a compile time one.

elBoberido · 2023-01-12T21:41:07Z

iceoryx_posh/cmake/IceoryxPoshDeployment.cmake

+macro(configure_option)
+    set(ONE_VALUE_ARGS NAME DEFAULT_VALUE)
+    cmake_parse_arguments(CONFIGURE_OPTION "" "${ONE_VALUE_ARGS}" "" ${ARGN})
+
+    if(NOT ${CONFIGURE_OPTION_NAME})
+        set(${CONFIGURE_OPTION_NAME} ${CONFIGURE_OPTION_DEFAULT_VALUE})
+    endif()
+    message(STATUS "[i] ${CONFIGURE_OPTION_NAME}: " ${${CONFIGURE_OPTION_NAME}})
+endmacro()


elBoberido · 2023-01-12T22:03:01Z

iceoryx_posh/cmake/IceoryxPoshDeployment.cmake

 # note: don't change IOX_INTERNAL_MAX_NUMBER_OF_NOTIFIERS value because it could break the C-Binding
-#if(NOT IOX_MAX_NUMBER_OF_NOTIFIERS)
+#configure_option(
+#    NAME IOX_MAX_NUMBER_OF_NOTIFIERS
+#    DEFAULT_VALUE 256
+#)
 set(IOX_INTERNAL_MAX_NUMBER_OF_NOTIFIERS 256)
-#endif()
-#message(STATUS "[i] IOX_MAX_NUMBER_OF_NOTIFIERS:" ${IOX_MAX_NUMBER_OF_NOTIFIERS})
+


I think this is a remnant of the v2 release crunch time. AFAIK the note is not true any more and we could remove INTERNAL. @elfenpiff @dkroenke please correct me if I'm wrong

@elBoberido @JakubSosnovec Yes this can be removed (but not necessarily in this PR to delay this not further here).

elBoberido · 2023-01-12T22:28:16Z

iceoryx_hoofs/include/iceoryx_hoofs/internal/cxx/convert.inl

-/// @NOLINTBEGIN(cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers)
-template <>
-inline bool convert::fromString<string<100>>(const char* v, string<100>& dest) noexcept
+template <uint64_t Capacity>


*cough* CString100 *cough*

…ization

JakubSosnovec · 2023-01-23T11:56:22Z

Rebased to latest master, to fix conflicts.

dkroenke

LGTM, thanks for the contribution.

JakubSosnovec changed the title ~~Iox 1803 expand cmake configuration options~~ iox-1803 expand cmake configuration options Nov 25, 2022

JakubSosnovec changed the title ~~iox-1803 expand cmake configuration options~~ iox-1803 Expand cmake configuration options Nov 25, 2022

elfenpiff requested review from elfenpiff and elBoberido November 25, 2022 09:54

elfenpiff reviewed Nov 25, 2022

View reviewed changes

budrus reviewed Nov 25, 2022

View reviewed changes

JakubSosnovec commented Nov 28, 2022

View reviewed changes

iceoryx_posh/BUILD.bazel Show resolved Hide resolved

mossmaurice assigned JakubSosnovec Nov 29, 2022

mossmaurice added the enhancement New feature label Nov 29, 2022

MatthiasKillat self-requested a review December 8, 2022 15:36

MatthiasKillat reviewed Dec 9, 2022

View reviewed changes

dkroenke reviewed Dec 14, 2022

View reviewed changes

dkroenke self-requested a review December 16, 2022 14:25

JakubSosnovec force-pushed the iox-1803-expand-cmake-configuration-options branch from c252858 to f22d406 Compare January 2, 2023 10:50

elBoberido previously approved these changes Jan 12, 2023

View reviewed changes

elfenpiff previously approved these changes Jan 16, 2023

View reviewed changes

JakubSosnovec added 7 commits January 23, 2023 12:43

iox-eclipse-iceoryx#1803 Avoid hard-coded convert::fromString special…

346a740

…ization

iox-eclipse-iceoryx#1803 Add new configuration options

2c64e21

iox-eclipse-iceoryx#1803 Add new example for small memory footprint

272c853

iox-eclipse-iceoryx#1803 Fix small_memory README typos

d3f4f76

iox-eclipse-iceoryx#1803 Avoid small_memory demo compilation

6118369

iox-eclipse-iceoryx#1803 Fix small_memory/README.md relative link

cf4caf4

iox-eclipse-iceoryx#1803 Fix MacOS build of small_memory demo

5be9378

JakubSosnovec added 6 commits January 23, 2023 12:48

iox-eclipse-iceoryx#1803 Fix Bazel build dict order

87c4555

iox-eclipse-iceoryx#1803 Add to release notes

a3e82a3

iox-eclipse-iceoryx#1803 Add test for fromString with cxx::string

e2daf31

iox-eclipse-iceoryx#1803 Remove unnecessary linter exceptions

cad2deb

iox-eclipse-iceoryx#1803 Add small_memory asciinema, example docs

2ceb0b3

iox-eclipse-iceoryx#1803 Fix small_memory asciinema user

ce3dddd

JakubSosnovec dismissed stale reviews from elfenpiff and elBoberido via ce3dddd January 23, 2023 11:55

JakubSosnovec force-pushed the iox-1803-expand-cmake-configuration-options branch from f22d406 to ce3dddd Compare January 23, 2023 11:55

dkroenke approved these changes Jan 23, 2023

View reviewed changes

elBoberido approved these changes Jan 23, 2023

View reviewed changes

elBoberido merged commit 72d9542 into eclipse-iceoryx:master Jan 23, 2023

iox-1803 Expand cmake configuration options #1804

iox-1803 Expand cmake configuration options #1804

Conversation

JakubSosnovec commented Nov 25, 2022 • edited by elBoberido Loading

Pre-Review Checklist for the PR Author

Notes for Reviewer

Checklist for the PR Reviewer

Post-review Checklist for the PR Author

References

elfenpiff left a comment

Choose a reason for hiding this comment

elfenpiff left a comment

Choose a reason for hiding this comment

JakubSosnovec commented Nov 25, 2022 • edited Loading

codecov bot commented Nov 25, 2022 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

budrus Nov 28, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

elBoberido commented Dec 1, 2022

MatthiasKillat left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MatthiasKillat Dec 9, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JakubSosnovec Dec 12, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MatthiasKillat Dec 9, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JakubSosnovec commented Jan 2, 2023

elBoberido left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JakubSosnovec commented Jan 23, 2023

dkroenke left a comment

Choose a reason for hiding this comment

JakubSosnovec commented Nov 25, 2022 •

edited by elBoberido

Loading

JakubSosnovec commented Nov 25, 2022 •

edited

Loading

codecov bot commented Nov 25, 2022 •

edited

Loading

budrus Nov 28, 2022 •

edited

Loading

MatthiasKillat Dec 9, 2022 •

edited

Loading

JakubSosnovec Dec 12, 2022 •

edited

Loading

MatthiasKillat Dec 9, 2022 •

edited

Loading