Use the spsc queue to pass jobs from TX thread (scheduler) to RX thread
(handling those jobs), reducing the amount spent searching for PUCCH
jobs in an array, clarifying the design, and making it thread-safe.
Signed-off-by: Robert Schmidt <robert.schmidt@openairinterface.org>
Because it is SPSC, atomic variables are enough to synchronize the two
threads. Concretely put() is modified to ensure that read_idx is
"acquired" so that the read index has been written, including memory, by
the other thread. "Release" ensures that the write operation (including
the memory to the buffer) is written before it is visible to the other
thread in get() (which in turn "acquires" it). For more information, see
also [1].
The rest of the library has been simplified to work only with put() and
get(), reducing total code and the surface for possible bugs.
This (and the previous) version has been tested with the
threadSanitizer:
TSAN_OPTIONS=halt_on_error=1 ./common/utils/ds/tests/test_spsc_q_perf
On my machine, using Google Benchmark, I measure a considerable 5x speed
improvement:
$ /tmp/benchmark/tools/compare.py benchmarks pthread.json atomic.json
Comparing pthread.json to atomic.json
Benchmark Time CPU Time Old Time New CPU Old CPU New
--------------------------------------------------------------------------------------------------------------
BM_spsc_q/10 -0.8201 -0.0740 266779912 47989020 52387 48512
BM_spsc_q/16 -0.8301 -0.0520 249656592 42428540 51462 48784
BM_spsc_q/32 -0.8003 -0.0841 230248798 45972155 53841 49311
BM_spsc_q/64 -0.7995 -0.0506 210429791 42199674 50690 48124
BM_spsc_q/128 -0.7930 -0.1101 205212273 42483155 52745 46936
BM_spsc_q/160 -0.7880 -0.1663 216644738 45938247 53400 44518
OVERALL_GEOMEAN -0.8057 -0.0904 0 0 0 0
[1] https://en.cppreference.com/w/c/atomic/memory_order.html
Assisted-By: Claude:claude-sonnet-4-6
Signed-off-by: Robert Schmidt <robert.schmidt@openairinterface.org>
This data structure is designed to support the use cases of the L1,
i.e., provide a queue which can be quickly used to order L1 jobs in FIFO
order with simple iteration of jobs to treat. It is a Single-Consumer
Single-Producer queue library.
Signed-off-by: Robert Schmidt <robert.schmidt@openairinterface.org>
phy_procedures_nr_gNB.c calls pack_srs() functions to pack individual
SRS "subPDUs". Correspondingly, the library depends on NFAPI_LIB. In
nr_ulsim, in a later commit, we will need to unpack the SRS.indication,
so remove dummy functions and implement correctly.
Signed-off-by: Robert Schmidt <robert.schmidt@openairinterface.org>
Integration `2026.w15`
* !4014 Microamp FR2 configuration file and documentation
* !4029 nr rlc: tolerate bogus data
* !4032 build_oai fixes: harmonize duplicate options, remove wrong --build-lib handling
* !3977 Further unused arguments cleanup
* !4009 Fix for NULL pucch-ResourceCommon at MSG4
* !4037 Increase reliability of ltebox start
* !4034 Prevent infinite loop on Single Entry PHR handling
* !4038 doc(record_db): explain how to use record_db
* fix compilation of T tracers with 'make'
* !3489 Thread-pool support for TX symbol processing.
See merge request oai/openairinterface5g!4033
Thread-pool support for TX symbol processing.
This MR adds thread-pool support for TX symbol processing. It allows modulation
/mapping/layer-precoding to run in parallel and offers a speedup of around 3
compared to single-thread execution. This is particularly important for large
bandwidths and 4 or more TX antenna ports where the precoding operation is quite
computationally-intensive.
Please see the description of !3489 for the performance comparison results and
the nr_dlsim timing measurements.
Extend the performance tuning section of documentation
to include explanation on the `--L1s.L1_num_tx_sym_per_thread` option
and on the AMD EPYC core complex behavior
Increase reliability of ltebox start
The existing ltebox startup sequence on nepes occasionally fails. Running
sudo su -c 'screen -dm -S simulated_hss /opt/hss_sim0609/starthss' \
&& sleep 1 && sudo /opt/ltebox/tools/start_mme && sudo /opt/ltebox/tools/start_xGw \
& sleep 1 && ip a show dev tun1
Reliably shows that no tun1 interface is created, because that takes around
1s itself. Increasing the second sleep to 2 reliably deploys it correctly.
Do the same for sabox and ltebox on nano for consistency.
Fix for NULL pucch-ResourceCommon at MSG4
Field pucch-ResourceCommon, used for ACK of MSG4, in some scenarios was
overwritten by RRCSetup before being used. Storing it in advance prevents
the segfault. In addition there is a clenaup of similar procedures at gNB.
* Add option `--L1s.L1_num_tx_sym_per_thread` for the softmodems and `-Y` for `nr_dlsim`
to provide the number of symbols processed per thread.
It defaults to 0 which makes that every symbols are processed in one thread.
* The last symbol processing task is processed in the L1 TX thread.
When receiving single-entry PHR with HARQ PID -1
(nr_mac_process_mac_pdu() is called with such parameter in at least two
places), the error handling path calls continue skipping the accounting
of the current sub-pdu (pduP and pdu_len). This results in an infinite
loop. Fix by moving functionality into a separate function.
Fixes: 2e0493632d ("RLC data ind: single call for complete TB at gNB")
Signed-off-by: Robert Schmidt <robert.schmidt@openairinterface.org>
Further unused arguments cleanup
More fixes for unused function arguments (see #1057),
add_compile_options(-Wunused-parameter) added in folders:
- nfapi
- openair2
- openair3
- USRP
- rfsimulator
build_oai fixes: harmonize duplicate options, remove wrong --build-lib handling
Correctly handle --build-lib such that missing arguments are still handled
properly. Harmonize, and remove useless code.
The existing ltebox startup sequence on nepes occasionally fails.
Running
sudo su -c 'screen -dm -S simulated_hss /opt/hss_sim0609/starthss' \
&& sleep 1 && sudo /opt/ltebox/tools/start_mme && sudo /opt/ltebox/tools/start_xGw \
& sleep 1 && ip a show dev tun1
Reliably shows that no tun1 interface is created, because that takes
around 1s itself. Increasing the second sleep to 2 reliably deploys it
correctly.
Do the same for sabox and ltebox on nano for consistency.
Signed-off-by: Robert Schmidt <robert.schmidt@openairinterface.org>
Functionality existed to print all output of asn1c on error, but the
form
asn1c || cat X
makes the command exit with a 0 exit code (success). Fix by explicitly
returning non-zero exit code in this case:
asn1c || ( cat X && false )
Signed-off-by: Robert Schmidt <robert.schmidt@openairinterface.org>
Both do practically the same. Harmonize them into one while guaranteeing
backwards compatibility.
Signed-off-by: Robert Schmidt <robert.schmidt@openairinterface.org>
This fixes two problem:
1. an omitted --build-lib library could yield strange grep errors. For
instance, calling build_oai --build-lib --cmake-opt OPTION passed
"--cmake-opt" to grep, that does not know this option. Handle by
explicitly separating options and search pattern through --.
2. Even with this fixed, set -e triggered an exit because grep exits
with non-zero error code. Remove set -e to have the error handling
code pass.
With set -e removed, properly check that the build passes.
Update a log line to make it clearer.
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Robert Schmidt <robert.schmidt@openairinterface.org>
nr rlc: tolerate bogus data
Some unfriendly entity may play with the RLC module and send bogus data to
trigger funky behaviors here and there.
A report sent by Dhanish indentifies one such issue.
From analyzing this report, a possible scenario is the following. Unfriendly
entity sends an RLC PDU with: is_first=0 is_last=0 so=15 lenght of data,
whatever, let's say 1.
This PDU is put in the RX list.
Then later it sends another PDU (for the same SN, obviously), with: is_first=1
is_last=1 so=0 (well, since is_first=1, necessarily so=0; it is not transmitted,
see 38.322 6.2.2.3 for UM and 38.322 6.2.2.4 for AM) length=10, let's say.
This PDU is also put in the RX list, before the previous one.
Then the function sdu_full() returns 1, so reassemble_and_deliver() is called
and the 'while (pdu)' loop is executed for both PDUs. When the second (bogus
one) is processed, so==10 (after processing the first PDU) and the line: int
len = pdu->size - (so - pdu->so) is: int len = 1 - (10 - 15) which is not good.
So we detect the case 'pdu->so > so' and reject the SDU. We could label the
other entity as bogus, since no standard RLC implementation will produce such a
case, but let's remain friendly, even with unfriendly entities. (To be changed
later if needed.)
The problem was reported for RLC AM but is also present in RLC UM. (Not in RLC
TM, where there is no segmentation.) Note: according to the report, this bug was
found using a fuzzer described as 'AI-assisted custom 5G NR protocol fuzzer'. It
had to be said.
* Global timers were started and stopped
in the TX symbol processing tasks
which is not thread safe
* gNBs nrL1_stats.log now shows
PDSCH generation time rather than
layer mapping and precoding times
There was an indexing error in the calculation of the symbol offset `re_beginning_of_symbol`.
The symbol was tested to hold PTRS or DMRS based on the index of the
first symbol processed in the task and not based on the index of the
symbol as it should be.
Then PDSCH generation was not working properly for more than one symbol
per task.
CI: Add stage to push to local git repository
This MR includes minor code cleanup and fixes for warnings reported by Jenkins.
It also introduces a new stage in ci-scripts/Jenkinsfile-GitLab-Container that
pushes the branch to a local repository after the merge. In a follow-up MR,
this local repository will be used as the source for cloning the branch,
replacing direct access to GitLab/GitHub.
Did you forget the `def` keyword? WorkflowScript seems to be setting a field named JOB_TIMESTAMP (to a value of type String) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? WorkflowScript seems to be setting a field named MR_NUMBER (to a value of type String) which could lead to memory leaks or other issues.
Some unfriendly entity may play with the RLC module and send bogus data to
trigger funky behaviors here and there.
A report sent by Dhanish, India, indentifies one such issue.
From analyzing this report, a possible scenario is the following.
Unfriendly entity sends an RLC PDU with:
is_first=0
is_last=0
so=15
lenght of data, whatever, let's say 1.
This PDU is put in the RX list.
Then later it sends another PDU (for the same SN, obviously), with:
is_first=1
is_last=1
so=0 (well, since is_first=1, necessarily so=0; it is not transmitted,
see 38.322 6.2.2.3 for UM and 38.322 6.2.2.4 for AM)
length=10, let's say.
This PDU is also put in the RX list, before the previous one.
Then the function sdu_full() returns 1, so reassemble_and_deliver() is
called and the 'while (pdu)' loop is executed for both PDUs. When the
second (bogus one) is processed, so==10 (after processing the first
PDU) and the line: int len = pdu->size - (so - pdu->so)
is: int len = 1 - (10 - 15)
which is not good.
So we detect the case 'pdu->so > so' and reject the SDU. We could label
the other entity as bogus, since no standard RLC implementation will
produce such a case, but let's remain friendly, even with unfriendly
entities. (To be changed later if needed.)
The problem was reported for RLC AM but is also present in RLC UM.
(Not in RLC TM, where there is no segmentation.)
Note: according to the report, this bug was found using a fuzzer
described as 'AI-assisted custom 5G NR protocol fuzzer'. It had
to be said.
Cleanup common_lib.h
This change reduces the number of dependecies of common_lib.h and simplifies
the task of implementing an external OAI radio library.
Robert Schmidt