tree aa71e4731686d27757305b47fc4b3cbc84fd40c6
parent a38c26595ff24fbeff1572e1df3db6409c343afe
author Vadim Yanitskiy <vyanitskiy@sysmocom.de> 1592591458 +0700
committer laforge <laforge@osmocom.org> 1592772409 +0000

library/RSL_Emulation: implement waiting queue for DChan messages

Since change [1] has been merged, we see multiple regressions in
ttcn3-bsc-test (all LCLS test cases) and ttcn3-bsc-test-sccplite
(sporadic failures). In all failed cases, the reason is similar:

  RSL for unknown Dchan
      BSC_Tests.ttcn:4501 BSC_Tests control part
      BSC_Tests.ttcn:2176 TC_assignment_codec_fr testcase

The mentioned change enables TCP_NODELAY option for all IPA based
connections, including both OML and RSL. This option disables
Nagle's algorithm [2], so we get less delays on IPA based links.

It took me a lot of time to investigate, and finally, I figured
out what is actually causing those regressions. The TCP_NODELAY
itself is not a problem, of course. As it turned out, the
problem is here, in our TTCN-3 test case framework.

Each test case involves several components (actors) running in parallel.
One of them is RSL_Emulation_CT, which is responsible for handling and
routing of RSL messages between the connected components.

A test case may register dedicated channel handlers by calling
f_rslem_register(), so DCHAN/RLL/IPACCESS messages will be matched
by RslChannelNr/TrxNr and routed to the corresponding one.

If no handler is found for a given RSL message, the RSL_Emulation_CT
would abort the test case execution. And that's where the problem is.

Given that all components are running in parallel, it may happen
that a received RSL message would be processed by the RSL emulation
component faster than the test case would call f_rslem_register().
The test case would be aborted due to "RSL for unknown Dchan".

Speaking in context of the failing BSC test cases, a test case
calls f_rslem_register() on receipt of an Assignment Command as
it contains all the assignment parameters. After that we expect
to receive an RSL ip.access CRCX for that channel.

The problem is that both Assignment Command and ip.access CRCX
messages are sent by the BSC simultaneously, so the later may
be handled faster than the first one. Race condition!

Let's work this around by maintaining a waiting queue, where the
messages, for which no handler was found, will be kept until the
corresponding dedicated channel is registered.

This is an optional feature that needs to be enabled explicitly
by calling f_rslem_dchan_queue_enable(), and then explicitly
disabled by calling f_rslem_dchan_queue_disable().

If at the moment of calling f_rslem_dchan_queue_disable() the
waiting queue is not empty, e.g. because the IUT sent us more
messages than we expected, test execution will be terminated.

The actial fix for the LCLS test cases will be submitted next.

[1] Ia3d4c41bf0659e682f0b7ae5f3d58ed0f28edb58
[2] https://en.wikipedia.org/wiki/Nagle%27s_algorithm

Change-Id: I25e10e28de174337233e6a3bb32cc16f2d7d614e
Related: OS#4619