Increase log buffer: handle large log messages

The logging's module output buffer was "only" 1500B. This cut off long messages, notably the per-UE MAC statistics output, and confused users. This increases the output buffer to 16384 bytes, which should be enough for 30-40 UEs. Beyond that, I think we should cut the output length (see also MR !1608 (closed)).

changed milestone to %REVIEW_CAN_START

added 5G-NR label

requested review from @frtabu

assigned to @francescomani

@AlSamman this MR fixes the problem with the output buffer that was capped for four or more UEs.

OAI RAN-CI-develop build (4153): failed (https://open5glab.eurecom.fr:8083/jenkins/job/RAN-CI-develop/4153/)

OAI RAN-Container-Parent build (2762): failed (https://jenkins-oai.eurecom.fr/job/RAN-Container-Parent/2762/)

Code Review by : François TABURET

• IMPACT on FUNCTIONAL CODE
  • The code change does NOT respect architecture/protocol split
  • Abnormal exits are NOT properly handled
  • Coding Style Issues
    • Added DEAD Code
    • Improper logging
    • Added useless debug code
    • Duplication of an existing function
    • Indentation is not respected
    • Insufficient in-code comments / code readability
    • Any other coding style issue
  • A new tool/lib/package has been introduced (blocking, subject to negotiation)
• TESTING (The Merge Request requires additional testing)
  • Additional testing is present in the Merge Request (Best)
  • The contributor provides a framework/hints for testing
  • New testing means need to be developed
• DOCUMENTATION (The Merge Request requires additional documentation)
  • Feature Set documentation update needed
    • DONE
    • NOT DONE
  • Wiki tutorial / in-repo usage documentation needed
    • DONE
    • NOT DONE
  • Added/Modified/Removed script/build/runtime option(s)
    • Help UPDATED
    • Help NOT UPDATED

Recommendations: Bug fixes, should be merged. Printing measurements and very big messages wasn't in the initial scope of the logging system: a first enhancement that could be considered would be to add a dedicated component id for MAC measurements.

This MR is labeled "5G" but i think that the fix will impact all executables using the logging module, even if they don't create messages longer than the current buffer limit. The risk of breaking these execs is very low, but....

thanks. Regarding the fact that this could impact 4G, the 4G pipelines are currently deactivated and will be enabled in MR !1697 (merged). We could wait with this MR or merge regardless. What do you think?

changed milestone to %REVIEW_COMPLETED_AND_APPROVED

changed title from Increase log buffer: handle large log messages to WIP: Increase log buffer: handle large log messages

changed title from WIP: Increase log buffer: handle large log messages to Increase log buffer: handle large log messages

OAI RAN-CI-develop build (4158): failed (https://open5glab.eurecom.fr:8083/jenkins/job/RAN-CI-develop/4158/)

OAI RAN-Container-Parent build (2767): passed (https://jenkins-oai.eurecom.fr/job/RAN-Container-Parent/2767/)

changed milestone to %OK_TO_BE_MERGED

mentioned in merge request !1722 (merged)

mentioned in commit bb396052

merged