under some circumstances it could happen that the RLC is configured
when SDUs are already being written to the queue. The resize
operation of the underlying container would fail in this case.
Make sure to empty the queue before doing the resize.
this patch fixes a bug discovered in a real network where the DL CQI of a
user degraded repidly in very short time. A relativly big RLC PDU that
was still sent with the good CQI in a big grant now needs to be split
across many tiny segments because the CQI degraded so much.
The retx couting for each transmitted segment caused the retx counter to
reach maxRetx quickly.
With this patch we do not increment the retx counter for each transmitted
PDU or segment of a PDU but instead only increment the counter when
a given SN is added to the retx queue. This can happen either:
a) if the SN is negativly acknowledged and was not already on the retx queue,
b) no new data is available for tx and a SN is selected for retx.
This is in accordance with TS 36.322 which handles retx counting in section
5.2.1 according to the above description.
the do_status is queried from the Tx code frequently. To reduce
chances to delay the execution because the RLC Rx side is currently
holding the mutex we can use an atomic.
the patch uses try-lock whenever a status PDU is tried
to be built. This makes sure that when the lock is currently
hold (e.g. by a thread processing rx PDUs) the generation
of the status PDUs is not taking too long and blocking the calling
thread. Instead the status PDU generation is deferred to the next
Tx opportunity.
It's a probabilistic approach that assumes that at some stage the
lock can in fact be acquired.
faluco
Andre Puschmann
Pedro Alvarez