this patch refactors the SDU queuing and dropping policy of the RLC and PDCP layer.
the previous design had issues when packets have been generated at a higher
rate above the PDCP than they could be consumed below the RLC.
When the RLC SDU queues were full, we allowed two policies, one to block on the write
and the other to drop the SDU. Both options are not ideal because they either
lead to a blocking stack thread or to lost PDCP PDUs.
To avoid this, this patch makes the following changes:
* PDCP monitors RLC's SDU queue and drops packets on its north-bound SAP if queues are full
* a new method sdu_queue_is_full() has been added to the RLC interface for PDCP
* remove blocking write from pdcp and rlc write_sdu() interface
* all writes into queues need to be non-blocking
* if Tx queues are overflowing, SDUs are dropped above PDCP, not RLC
* log warning if RLC still needs to drop SDUs
* this case should be avoided with the monitoring mechanism
when adding a new subheader to a MAC PDU we should only add the subheader
if at least 2 bytes are left in the PDU. Even a 1 Byte MAC Control Element requires
another byte to pack the subheader.
This fixes#1424 in which a 3 B MAC opportunity is provided in the UL. After
adding the Short BSR, we tried to add another MAC subheader. Adding the subheader
succeeded even though no space is left to add a single byte. With this patch,
adding the subheader fails and the generates MAC PDU is correct.
with ZMQ RF, we've seen the radio returning -1 and traced
the issue down to the ringbuffer.
in fact, pthread_cond_timedwait() returned 22 (EINVAL) indicating
a wrong timeout value. The issue was likely an overflow
in the timespec parameter. This patch checks for the return
value of pthread_cond_timedwait() and also calculates the
nanosecond wrap around for the timespec
amarisoft flags an RF error and exits after not receiving samples
for the radio. Running with ZMQ in the RFCI, the UE sometimes needs more
time to start up due to slow processing and no fftw wisdom file and
then Amarisoft eNB times out. This gives the whole process a little
bit more time. Should we still find it too short we may increase
it further.
This lock was removed in 1cbf7eac because it was considered unneeded.
However, as can be seen in issue #1503, we need to protect the access
to rx_window, for example.
Issue #1503 shows a stack trace where a PHY worker generates a status PDU.
While holding the mutex to access rx_window, the stack thread on the
other hand, happily accesses the rx_window member without acquiring
the lock. This commit protects all handle_*() functions in write_pdu().
This reverts commit 1cbf7eac04.
instead of logging PDU received from below, and SDU that is forwarded
to above, only log the PDU in rx in info mode.
The next layer will do the same and log the PDU received (which is the SDU coming from here)
so there is now loss of information in the logs.
Here is the test output with the fix disabled:
13:47:42.679774 [RLC_UM_1] [D] MAC opportunity - 14 bytes
13:47:42.679784 [RLC_UM_1] [D] pdu_space=14, head_len=2
13:47:42.679790 [RLC_UM_1] [D] adding new SDU segment - 10 bytes of 10 remaining
13:47:42.679834 [RLC_UM_1] [D] Complete SDU scheduled for tx. Stack latency: 0 us
13:47:42.679909 [RLC_UM_1] [D] pdu_space=4, head_len=2
13:47:42.679922 [RLC_UM_1] [D] adding new SDU segment - 0 bytes of 10 remaining
13:47:42.679928 [RLC_UM_1] [I] Tx PDU SN=0 (14 B)
13:47:42.679974 [RLC_UM_1] [D] vt_us = 1
The test checks the correct packing and of the two PDUs at the end.
during the PDU packing it could happen that a new SDU segment
was added but the resulting larger header was so big that not even
a single byte of the new PDU could be added. because this
corner case wasn't handled correctly an invalid PDU was transmitted.
the solution is to revert the addition of the new SDU.
Francisco Paisana
Andre Puschmann
Xavier Arteaga
Pedro Alvarez
Ismael Gomez