Increase configurability to allow smaller memory consumption

[JakubSosnovec]

The iceoryx management segment is still quite large, even if the configuration options in CMake are set to be very small. It would be good to increase the number of constants that can be easily configured via CMake to make it possible to further decrease the memory consumption of iceoryx.

For example, suppose we set the configurable limits of iceoryx to a bare minimum:
cmake -DIOX_MAX_PUBLISHERS=8 -DIOX_MAX_SUBSCRIBERS=8 -DIOX_MAX_PUBLISHER_HISTORY=1 -DIOX_MAX_SUBSCRIBERS_PER_PUBLISHER=5 -DIOX_MAX_CHUNKS_ALLOCATED_PER_PUBLISHER_SIMULTANEOUSLY=2 -DIOX_MAX_CHUNKS_HELD_PER_SUBSCRIBER_SIMULTANEOUSLY=2 -DIOX_MAX_INTERFACE_NUMBER=1 ../iceoryx_meta

Then, the iceoryx_mgmt segment has 20 MBs. Of course, that is fine on large hosted environments. However, in our experiments porting iceoryx to FreeRTOS on smaller embedded platforms, this is still too much.

Note that we are not actually trying to get iceoryx to something very small, like a Cortex-M0 with only tens of kilobytes of memory. We are targeting a reasonable powerful Cortex-M7 with 3 cores (for now, we are just running on one core) and 8 MB of memory. In an ideal world, we would squeeze the code size and the iceoryx segments (management and chunk pool) into 1 MB in total, so that we have the remaining memory for other usage.

In fact, we managed to get the memory consumption under 3 MB, by manually reducing some global constants, which we found to affect the management segment size (and perhaps the code size, too) the most. In particular, we reduced:

• MAX_IPC_CHANNEL_NAME_LENGTH to 20
• NamedPipe::MAX_MESSAGE_SIZE to 256
• NamedPipe::MAX_NUMBER_OF_MESSAGES to 5
• MAX_NUMBER_OF_CONDITION_VARIABLES to 5
• MAX_NUMBER_OF_MEMPOOLS to 5
• MAX_SHM_SEGMENTS to 1
• MAX_PROCESS_NUMBER to 5
• MAX_NODE_NUMBER to 5
• MAX_NODE_PER_PROCESS to 5
• NodeName_t capacity to 20
• IdString_t capacity to 20

And, actually, even with these greatly reduced constants, we are able to run a very basic demo.

I dont quite understand all the details of what all these constants do, so I am not sure how much limiting it is to reduce them so much. Perhaps some of them dont need to be reduced so much. However, overall, it might be a good idea to increase the configurability of iceoryx and thus enable to control the memory consumption a bit better.

[elfenpiff]

@JakubSosnovec

I try to provide you with as much details as possible to the constants so that you also have some context:

MAX_IPC_CHANNEL_NAME_LENGTH

This corresponds with the app name you set on startup in iox::runtime::PoshRuntime::initRuntime(APP_NAME); If you are alright with a one letter APP_NAME the value 1 should work (or maybe two when somewhere a slash is stored)

NamedPipe::MAX_MESSAGE_SIZE

Here I would be cautious. This could lead to weird surprises when you use it in combination with findService. If you have a lot of services running in your system and you want a complete list of all of them. The result must fit into this message size, furthermore it is used to acquire ports from roudi and register the application. But when all your service names, app names etc are small and you do not use findService you can reduce it even further.

NamedPipe::MAX_NUMBER_OF_MESSAGES

The amount of messages roudi can cache before apps cannot sendout messages anymore.

MAX_NUMBER_OF_CONDITION_VARIABLES

Used in waitset and listener, if you do not use those constructs you could reduce it even further

MAX_NUMBER_OF_MEMPOOLS

When setting up a custom memory config it defines how many mempools you can configure, see: https://github.com/eclipse-iceoryx/iceoryx/blob/master/doc/website/advanced/configuration-guide.md#dynamic-configuration

MAX_PROCESS_NUMBER

This is the amount of processes which can register at roudi

MAX_NODE_NUMBER

We actually dont use this and this could in theory be zero, or one?

MAX_NODE_PER_PROCESS

Same here

NodeName_t

Can be zero or one

IdString_t

The length of the service, instance, event strings in the service description. Reducing those numbers is a real memory safer! If you can deal with one letter names in this triplet I would reduce it to 1.

[JakubSosnovec]

@elfenpiff @elBoberido

Thanks a lot for the comments and suggestions! I appreciate the explanation of what the constants influence.

I will definitely play around with the constants a bit more, to try to squeeze the size. I like your words about aiming for under 500kB, thats music for my ears! :)

Would you guys consider adding a way to set the constants during configuration phase, like the IOX_* cmake options? Then, the user who wants to change the defaults (like me) doesnt have to maintain a fork of iceoryx, but only a set of configuration options.

[elBoberido]

@elfenpiff it seems you want to prove Gill Gates comment 640K ought to be enough for anybody. right

[elfenpiff]

@JakubSosnovec

Would you guys consider adding a way to set the constants during configuration phase, like the IOX_* cmake options?

Sure no problem! We were talking about this at lunch today and an idea like that also popped into our minds in combination with an example which demonstrates how to reduce the memory footprint of iceoryx.

I would proceed like this:

1. Play around with the constants until we know which of them we put into cmake.
2. Then we create the example and put those constants into cmake.

Now the question. Would you be willing to add the constants into the cmake file or should we do it? But it would also be no problem for me since I would really like to write this example.

[elBoberido]

@JakubSosnovec @elfenpiff I think it would be nice to set the constants via a cmake toolchain file

[JakubSosnovec]

@elfenpiff Sure, I will take that task :)