Inconsistent default values for cmd pipe depth across apps
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 1.5k
- Forks
- 391
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 19
Description
Checklist (Please check before submitting)
- I reviewed the Contributing Guide.
- I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.
Describe the bug
All apps have a setting to control the depth (and name, ideally) of their respective command input pipe.
The problem is many of these are hardcoded to an integer number that is often much larger than it really needs to be.
For example DS has its pipe depth configured to 45. This is very large.
CFE SB had its pipe depth fixed at 32 and was non-configurable, as it was in a local header file.
As most linux distros will (by default) limit POSIX message queue pipe depth to 10, the CFS defaults should also work with OS_QUEUE_MAX_DEPTH set to 10, since this would be the "proper" solution (as opposed to the debug solution of silently truncating the depth to 10 even though a larger queue was requested).
To Reproduce
Set OS_QUEUE_MAX_DEPTH osal configuration parameter to 10 so it will boot normally on an un-tweaked Linux kernel without needing root privileges.
Some apps will fail to compile with default config, other apps will fail to boot even if they do compile.
Expected behavior
All apps should compile and boot with the queue depth set to 10.
The approach should be to use the conservative (but universally supportable) value as the default. A depth of 10 is more than enough so long as there is no CPU contention (i.e. tasks wake up to service their queue in a timely fashion).
System observed on:
Linux
Additional context
The user can extend/increase the value if their needs dictate, but a need for a deep queue depth probably indicates a more fundamental architectural issue like a CPU not having enough margin to process the workloads effectively. In these scenarios where the consumer is not keeping pace with the sender and multiple items start backing up, a deeper queue usually just delays the failure, it does not fix it.
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the command input pipe defaults for DS and CFE SB, then review the other apps' settings alongside the OS_QUEUE_MAX_DEPTH configuration. Build and boot the apps with OS_QUEUE_MAX_DEPTH set to 10; done means every app compiles and boots without requiring a larger queue depth.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- embedded-iot, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100