March 2024 - gerrit-log - lists.osmocom.org

[L] Change in osmo-mgw[master]: Convert RTP/RTCP/OSMUX I/O from osmo_fd to osmo_io

by laforge

Attention is currently required from: dexter, laforge, neels, pespin. Hello Jenkins Builder, dexter, neels, pespin, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-mgw/+/36363?usp=email to look at the new patch set (#4). The following approvals got outdated and were removed: Verified-1 by Jenkins Builder Change subject: Convert RTP/RTCP/OSMUX I/O from osmo_fd to osmo_io ...................................................................... Convert RTP/RTCP/OSMUX I/O from osmo_fd to osmo_io Converting from osmo_fd to osmo_io allows us to switch to the new io_uring backend and benefit from related performance benefits. In a benchmark running 200 concurrent bi-directional voice calls with GSM-EFR codec, I am observing: * the code before this patch uses 40..42% of a single core on a Ryzen 5950X at 200 calls (=> 200 endpoints with each two connections) * no increase in CPU utilization before/after this patch, i.e. the osmo_io overhead for the osmo_fd backend is insignificant compared to the direct osmo_fd mode before * an almost exactly 50% reduction of CPU utilization when running the same osmo-mgw build with LIBOSMO_IO_BACKEND=IO_URING - top shows 19..21% for the same workload instead of 40..42% with the OSMO_FD default backend. * An increase of about 4 Megabytes in both RSS and VIRT size when enabling the OSMO_IO backend. This is likely the memory-mapped rings. No memory leakage is observed when using either of the backends. Change-Id: I8471960d5d8088a70cf105f2f40dfa5d5458169a --- M include/osmocom/mgcp/mgcp.h M include/osmocom/mgcp/mgcp_network.h M src/libosmo-mgcp/mgcp_conn.c M src/libosmo-mgcp/mgcp_iuup.c M src/libosmo-mgcp/mgcp_network.c M src/libosmo-mgcp/mgcp_osmux.c M tests/mgcp/mgcp_test.c 7 files changed, 232 insertions(+), 169 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-mgw refs/changes/63/36363/4 -- To view, visit https://gerrit.osmocom.org/c/osmo-mgw/+/36363?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-mgw Gerrit-Branch: master Gerrit-Change-Id: I8471960d5d8088a70cf105f2f40dfa5d5458169a Gerrit-Change-Number: 36363 Gerrit-PatchSet: 4 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-MessageType: newpatchset

3 months, 1 week

1
0
0 0

[S] Change in osmo-trx[master]: code-architecture.adoc: Fix missing alignment in digraph

by fixeria

Attention is currently required from: pespin. fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-trx/+/36464?usp=email ) Change subject: code-architecture.adoc: Fix missing alignment in digraph ...................................................................... Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/36464?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-trx Gerrit-Branch: master Gerrit-Change-Id: I9077590f6786833c9a86c3e844fc2dd07b404d58 Gerrit-Change-Number: 36464 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 26 Mar 2024 18:24:05 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

3 months, 1 week

1
0
0 0

[S] Change in osmo-ttcn3-hacks[master]: [cosmetic] mgw: fix spelling in comments

by laforge

laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36463?usp=email ) Change subject: [cosmetic] mgw: fix spelling in comments ...................................................................... [cosmetic] mgw: fix spelling in comments Change-Id: I2fb69463b070cdc183fff63ee7dc422169f8928a --- M mgw/MGCP_Test.ttcn 1 file changed, 12 insertions(+), 3 deletions(-) Approvals: Jenkins Builder: Verified pespin: Looks good to me, approved diff --git a/mgw/MGCP_Test.ttcn b/mgw/MGCP_Test.ttcn index b7d6b46..3161079 100644 --- a/mgw/MGCP_Test.ttcn +++ b/mgw/MGCP_Test.ttcn @@ -2703,7 +2703,7 @@ mgcp_transceive_mgw(cmd, tr_CRCX_ACK); } - /* Wait until the stats items have seteled and then check if we get the expected number (all) of + /* Wait until the stats items have settled and then check if we get the expected number (all) of * occupied endpoints */ f_sleep(1.0) expect := { @@ -2724,14 +2724,14 @@ cmd := ts_DLCX(get_next_trans_id(), ep); mgcp_transceive_mgw(cmd, rtmpl); - /* Query a the statsd once to ensure that intermediate results are pulled from the + /* Query the statsd once to ensure that intermediate results are pulled from the * pipeline. The second query (below) will return the actual result. */ expect := { { name := "TTCN3.trunk.e1-1.common.endpoints.used", mtype := "g", min := 0, max := n_e1_ts * 4} }; f_statsd_expect(expect); - /* The second query must resturn a result with 0 endpoints in use. */ + /* The second query must return a result with 0 endpoints in use. */ expect := { { name := "TTCN3.trunk.e1-1.common.endpoints.used", mtype := "g", min := 0, max := 0} }; -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36463?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I2fb69463b070cdc183fff63ee7dc422169f8928a Gerrit-Change-Number: 36463 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: merged

3 months, 1 week

1
0
0 0

[S] Change in osmo-ttcn3-hacks[master]: ggsn: Avoid dynamic test case error

by laforge

laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36461?usp=email ) Change subject: ggsn: Avoid dynamic test case error ...................................................................... ggsn: Avoid dynamic test case error During TC_addr_pool_exhaustion, if all of the pdp context activations were unsuccessful, teic_list is an empty list. We therefore cannot unconditionally obtain its first element. This patch avoids the related "Index overflow in a value of type @PreGenRecordOf.PREGEN_RECORD_OF_OCTETSTRING: The index is 0, but the value has only 0 elements." Related: OS#6423 Change-Id: I7c7a84ed8343fb48e841248f86d37972f4674ed0 --- M ggsn_tests/GGSN_Tests.ttcn 1 file changed, 19 insertions(+), 1 deletion(-) Approvals: osmith: Looks good to me, but someone else must approve Jenkins Builder: Verified pespin: Looks good to me, approved diff --git a/ggsn_tests/GGSN_Tests.ttcn b/ggsn_tests/GGSN_Tests.ttcn index e2d5fb2..8672947 100644 --- a/ggsn_tests/GGSN_Tests.ttcn +++ b/ggsn_tests/GGSN_Tests.ttcn @@ -2080,7 +2080,7 @@ [Gx_PROC.checkstate("Connected")] as_DIA_Gx_CCR(TERMINATION_REQUEST) { repeat; } [Gy_PROC.checkstate("Connected")] as_DIA_Gy_CCR(omit, TERMINATION_REQUEST) { repeat; } [] pingpong(); - [] T_next.timeout { + [lengthof(teic_list) > 0] T_next.timeout { f_send_gtpc(ts_GTPC_DeletePDP(g_peer_c, g_c_seq_nr, teic_list[next_req_ctx], '0001'B, '1'B)); next_req_ctx := next_req_ctx + 1; if (next_req_ctx < num_ctx) { -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36461?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I7c7a84ed8343fb48e841248f86d37972f4674ed0 Gerrit-Change-Number: 36461 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: merged

3 months, 1 week

1
0
0 0

[S] Change in osmo-trx[master]: code-architecture.adoc: Fix missing alignment in digraph

by laforge

Attention is currently required from: pespin. laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-trx/+/36464?usp=email ) Change subject: code-architecture.adoc: Fix missing alignment in digraph ...................................................................... Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/36464?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-trx Gerrit-Branch: master Gerrit-Change-Id: I9077590f6786833c9a86c3e844fc2dd07b404d58 Gerrit-Change-Number: 36464 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 26 Mar 2024 18:11:03 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

3 months, 1 week

1
0
0 0

[L] Change in osmo-trx[master]: doc: Introduce documentation for osmo-trx-ipc and its IPC interface

by laforge

Attention is currently required from: Hoernchen, fixeria, osmith, pespin. laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email ) Change subject: doc: Introduce documentation for osmo-trx-ipc and its IPC interface ...................................................................... Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-trx Gerrit-Branch: master Gerrit-Change-Id: Id6863731f9398720030b16efaaf559e05f2444ed Gerrit-Change-Number: 36465 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Hoernchen <ewild(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Attention: osmith <osmith(a)sysmocom.de> Gerrit-Attention: Hoernchen <ewild(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Tue, 26 Mar 2024 18:10:52 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

3 months, 1 week

1
0
0 0

[L] Change in osmo-trx[master]: doc: Introduce documentation for osmo-trx-ipc and its IPC interface

by pespin

pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email ) Change subject: doc: Introduce documentation for osmo-trx-ipc and its IPC interface ...................................................................... doc: Introduce documentation for osmo-trx-ipc and its IPC interface Related: SYS#6861 Change-Id: Id6863731f9398720030b16efaaf559e05f2444ed --- M doc/manuals/chapters/code-architecture.adoc A doc/manuals/chapters/ipc_if.adoc M doc/manuals/chapters/trx-backends.adoc M doc/manuals/osmotrx-usermanual.adoc 4 files changed, 411 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-trx refs/changes/65/36465/1 diff --git a/doc/manuals/chapters/code-architecture.adoc b/doc/manuals/chapters/code-architecture.adoc index 1cb2542..5311dbe 100644 --- a/doc/manuals/chapters/code-architecture.adoc +++ b/doc/manuals/chapters/code-architecture.adoc @@ -17,6 +17,7 @@ 7[label = "{UHDDevice|...}"] 8[label = "{LMSDevice|...}"] 9[label = "{USRPDevice|...}"] +10[label = "{IPCDevice|...}"] 2->3[arrowtail=odiamond] 3->4[constraint=false] @@ -25,6 +26,7 @@ 6->7 6->8 6->9 +6->10 } ---- diff --git a/doc/manuals/chapters/ipc_if.adoc b/doc/manuals/chapters/ipc_if.adoc new file mode 100644 index 0000000..1e1f2bd --- /dev/null +++ b/doc/manuals/chapters/ipc_if.adoc @@ -0,0 +1,302 @@ +[[ipc_if]] +== osmo-trx-ipc IPC Interface + +This interface is the one used by _osmo_trx_ipc_ backend to communicate to a +third party process in charge of driving the lowest layer device-specific bits +(from now on the Driver). + +It consists of a set of Unix Domain (UD) sockets for the control plane, plus a +shared memory region for the data plane. + +Related code can be found in the +https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/master/Transceiver52M/device/ipc[Transceiver52M/device/ipc/] +directory in _osmo-trx.git_. + +If you are a potential driver implementator, the +different primitives and data structures are publicly available in header file +https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/master/Transceiver52M/device/ipc/shm.h[Transceiver52M/device/ipc/shm.h]. + +=== Control plane + +Control plane protocol is transmitted over Unix Domain (UD) sockets using +message based primitives. Each primitive has a type identified by an integer, +and each type of primitive has a number of extra attributes attached to it. The +IPC interface consists of 2 types of UD sockets: + +* _Master_ UD socket: One per osmo-trx-ipc process. + +* _Channel_ UD socket: One for +each channel managed by osmo-trx-ipc process. + +The _Driver_ is in all cases expected to take the server role when creating UD +sockets, while _osmo-trx-ipc_ takes the client role and connects to sockets +provided by the driver. + +=== Master UD socket + +During startup, _osmo-trx-ipc_ will try connecting to the _Driver_ Master UD +socket located in the path provided by its own (VTY) configuration. As a result, +it means the _Driver_ process must be running and listening on the Master UD +socket before _osmo-trx-ipc_ is started, otherwise _osmo-trx-ipc_ will fail and +exit. + +Once connected, _osmo-trx-ipc_ will submit a `GREETING_REQ` message primitive +announcing the maximum supported protocol version (first version ever is `1`, +increasing over time). + +The _Driver_ shall then answer in `GREETING_CNF` message primitive with its own +maximum supported version (`<=` version received), providing 0 if none is +supported. + +If _osmo-trx-ipc_ receives back the requested version, then both sides agreed +on the protocol version to use. +If _osmo-trx-ipc_ receives back a lower version, it shall decide to continue +with version negotiation using a lower version, until a supported version or 0 +is received. If finally 0 is received, _osmo-trx-ipc_ will disconnect and exit +with failure. + +Once the version is negotiated (`v1` as of current date), _osmo-trx-ipc_ will +ask for device information and available characeristics to the _Driver_ using +the `INFO_REQ` message primitive. + +The _Driver_ shall then answer with a `INFO_CNF` message +containing information, such as: + +* String containing device description + +* Available reference clocks, + +* {rx,tx} I/Q scaling factors + +* Maximum number of channels supported + +* for each channel: + +** List of available {rx,tx} paths/antennas. + +** {min,max}{rx,tx} gains + +** Nominal transmit power + +All the information received from the _Driver_ during `INFO_CNF` will be used by +_osmo-trx-ipc_ to decide whether it can fullfil the requested configuration from +the user, and proceed to open the device, or exit with a failure (for instance +number of channels, referece clock or tx/rx antenna selected by the user cannot +be fullfilled). + +_osmo-trx-ipc_ will then proceed to open the device and do an initial +configuration using an `OPEN_REQ` message, where it will provide the _Driver_ +with the desired selected configuration (such as number of channels, rx/tx +paths, clock reference, bandwidth filters, etc.). + +The _Driver_ shall then configure the device and send back a `OPEN_CNF` with: + +* `return_code` integer attribute set to `0` on success or `!0` on error. + +* Name of the Posix Shared Memory region where data plane is going to be +transmitted. + +* One path for each channel, containing the just-created UD socket to manage +that channel (for instance by taking Master UD socket path and appending +`_$chan_idx`). + +* Path Delay: this is the loopback path delay in samples (= used as a timestamp +offset internally by _osmo-trx-ipc_), this value contains the analog delay as +well as the delay introduced by the digital filters in the fpga in the sdr +devices, and is therefore device type and bandwidth/sample rate dependant. This +can not be omitted, wrong values will lead to a _osmo-trx-ipc_ that just doesn't +detect any bursts. + +Finally, _osmo-trx-ipc_ will connect to each channel's UD socket (see next +section). + +Upon _osmo-trx-ipc_ closing the UD master socket connection, the _Driver_ shall +go into @closed@ state: stop all processing and instruct the device to power +off. + +TIP: See +https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/master/Transceiver52M/device/ipc/shm.h[Transceiver52M/device/ipc/shm.h] +for the detailed definition of all the related message primitives and data +types for this socket. + +=== Channel UD Socket + +This socket can be used by _osmo-trx-ipc_ to start/stop data plane processing or +change channel's parameters such as Rx/Tx Frequency, Rx/Tx gains, etc. + +A channel can be either in _started_ or _stopped_ state. When a channel is +created (during `OPEN_REQ` in the Master UD Socket), it's by default in +_stopped_ state. `START_REQ` and `STOP_REQ` messages control this state, and +eventual failures can be reported through `START_CNF` and `STOP_CNF` by the +_Driver_. + +The message `START_REQ` instructs the _Driver_ to start processing data in the +data plane. Similary, `STOP_REQ` instructs the _Driver_ to stop processing data +in the data plane. + +Some parameters are usually changed only when the channel is in stopped mode, +for instance Rx/Tx Frequency. + +TIP: See +https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/master/Transceiver52M/device/ipc/shm.h[Transceiver52M/device/ipc/shm.h] +for the detailed definition of all the related message primitives and data +types for this socket. + +=== Data Plane + +Data plane protocol is implemented by means of a ring buffer structure on top of +Posix Shared Memory (see `man 7 shm_overview`) between _osmo-trx-ipc_ process +and the _Driver_. + +The Posix Shared Memory region is created and its memory structure prepared by +the _Driver_ and its name shared with _osmo-trx-ipc_ during _OPEN_CNF_ message +in the Master UD Socket from the Control Plane. Resource allocation for the +shared memory area and cleanup is up to the ipc server, as is mutex +initialization for the buffers. + +==== Posix Shared Memory structure + +[[fig-shm-structure]] +.General overview of Posix Shared Memory structure +[graphviz] +---- +digraph hierarchy { +node[shape=record,style=filled,fillcolor=gray95] +edge[dir=back, arrowtail=empty] + +SHM[label = "{Posix Shared Memory region|+ num_chans\l+ Channels[]\l}"] +CHAN0[label = "{Channel 0|...}"] +CHAN1[label = "{Channel 1|...}"] +CHANN[label = "{Channel ...|}"] +STREAM0_UL[label = "{UL Stream|+ semaphore\l+ read_next\l+write_next\l+ buffer_size /* In samples */\l+ num_buffers\l+ sample_buffers[]\l}"] +STREAM0_DL[label = "{DL Stream|+ semaphore\l+ read_next\l+write_next\l+ buffer_size /* In samples */\l+ num_buffers\l+ sample_buffers[]\l}"] +STREAM1_UL[label = "{UL Stream|...}"] +STREAM1_DL[label = "{DL Stream|...}"] +STREAMN_UL[label = "{UL Stream|...}"] +STREAMN_DL[label = "{DL Stream|...}"] +BUF_0DL0[label = "{DL Sample Buffer 0|+ timestamp\l+ buffer_size /* In samples */\l+ samples[] = [16bit I + 16bit Q,...]\l}"] +BUF_0DLN[label = "{DL Sample Buffer ....|...}"] +BUF_0UL0[label = "{UL Sample Buffer 0|+ timestamp\l+ buffer_size /* In samples */\l+ samples[] = [16bit I + 16bit Q,...]\l}"] +BUF_0ULN[label = "{UL Sample Buffer ...|...}"] + +SHM->CHAN0 +SHM->CHAN1 +SHM->CHANN + +CHAN0->STREAM0_DL +CHAN0->STREAM0_UL +STREAM0_DL->BUF_0DL0 +STREAM0_DL->BUF_0DLN +STREAM0_UL->BUF_0UL0 +STREAM0_UL->BUF_0ULN + +CHAN1->STREAM1_UL +CHAN1->STREAM1_DL + +CHANN->STREAMN_UL +CHANN->STREAMN_DL +} +---- + +The Posix Shared Memory region contains an array of _Channels_. + +Each _Channel_ contains 2 Streams: + +* Downlink _Stream_ + +* Uplink _Stream_ + +Each _Stream_ handles a ring buffer, which is implemented as: + +* An array of pointers to _Sample Buffer_ structures. + +* Variables containing the number of buffers in the array, as well as the +maximum size in samples for each Sample Buffer. + +* Variables containing `next_read` and `next_write` _Sample Buffer_ (its index +in the array of pointers). + +* Unnamed Posix semaphores to do the required locking while using the ring +buffer. + +Each _Sample Buffer_ contains: + +* A `timestamp`` variable, containing the position in the stream of the first +sample in the buffer + +* A `data_len`` variable, containing the amount of samples available to process +in the buffer + +* An array of samples of size specified by the stream struct it is part of. + +==== Posix Shared Memory format + +The Posix Shared memory region shall be formatted applying the following +considerations: + +* All pointers in the memory region are encoded as offsets from the start +address of the region itself, to allow different processes with different +address spaces to decode them. + +* All structs must be force-aligned to 8 bytes + +* Number of buffers must be power of 2 (2,4,8,16,...) - 4 appears to be plenty + +* IQ samples format: One (complex) sample consists of 16bit i + 16bit q, so the +buffer size is number of IQ pairs. + +* A reasonable per-buffer size (in samples) is 2500, since this happens to be +the ususal TX (downlink) buffer size used by _osmo-trx-ipc_ with the b210 (rx +over-the-wire packet size for the b210 is 2040 samples, so the larger value of +both is convenient). + +TIP: See +https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/master/Transceiver52M/device/ipc/shm.h[Transceiver52M/device/ipc/shm.h] +for the detailed definition of all the objects being part of the Posix Shared +memory region structure + +==== Posix Shared Memory procedures + +The queue in the shared memory area is not supposed to be used for actual +buffering of data, only for exchange, so the general expectation is that it is +mostly empty. The only exception to that might be minor processing delays, and +during startup. + +Care must be taken to ensure that only timed waits for the mutex protecting it +and the condition variables are used, in order to ensure that no deadlock occurs +should the other side die/quit. + +Thread cancellation should be disabled during reads/writes from/to the queue. In +general a timeout can be considered a non recoverable error during regular +processing after startup, at least with the current timeout value of one second. + +Should over- or underflows occur a corresponding message should be sent towards +_osmo-trx-ipc_. + +Upon **read** of `N`` samples, the reader does something like: + +. Acquire the semaphore in the channel's stream object. + +. Read `stream->next_read`, if `next_read==next_write`, become blocked in +another sempahore (unlocking the previous one) until writer signals us, then +`buff = stream->buffers[next_read]` + +. Read `buff->data_len` samples, reset the buffer data (`data_len=0``), +increment `next_read` and if read samples is `<N``, continue with next buffer +until `next_read==next_write``, then block again or if timeout elapsed, then we +reach conditon buffer underflow and `return len < N``. + +. Release the semaphore + +Upon **write** of `N`` samples, the writer does something like: + +. Acquire the semapore in the channel's stream object. + +. Write samples to `buff = stream->buffers[next_write]`. If `data_len!=0``, +signal `buffer_overflow`` (increase field in stream object) and probably +increase next_read``. + +. Increase `next_write``. + +. If `next_write was == next_read``, signal the reader through the other +semaphore that it can continue reading. \ No newline at end of file diff --git a/doc/manuals/chapters/trx-backends.adoc b/doc/manuals/chapters/trx-backends.adoc index 78bc45d..e5cacec 100644 --- a/doc/manuals/chapters/trx-backends.adoc +++ b/doc/manuals/chapters/trx-backends.adoc @@ -71,3 +71,98 @@ in a buffer, and read commands to the USRP simply pull data from this buffer. This was very useful in early testing, and still may be useful in testing basic Transceiver and radioInterface functionality. + + +[[backend_ipc]] +=== `osmo-trx-ipc` Inter Process Communication backend + +This OsmoTRX model provides its own Inter Process Communication (IPC) interface +to drive the radio device driver (from now on the Driver), allowing for third +party processes to implement the lowest layer device-specific bits without being +affected by copyleft licenses of OsmoTRX. + +For more information on such interface, see section <<ipc_if>>. + +[[fig-backend-ipc]] +.Architecture with _osmo-trx-ipc_ and its IPC _Driver_ +[graphviz] +---- +digraph G { + rankdir=LR; + MS0 [label="MS"]; + MS1 [label="MS"]; + OsmoTRX [label="osmo-trx-ipc", color=red]; + BTS; + + subgraph cluster_ipc_driver { + label = "IPC Driver"; + color=red; + RE [label = "Radio Equipment"]; + REC [label="Radio Equipment Controller"]; + RE->REC; + } + + REC->OsmoTRX [label="IPC Interface", color=red]; + + MS0->RE [label="Um"]; + MS1->RE [label="Um"]; + OsmoTRX->BTS [label="bursts over UDP"]; + +} +---- + +A sample config file for this OsmoTRX model can be found in _osmo-trx.git_ https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/maste… + +In the config file, the following VTY command can be used to set up the IPC UD Master Socket _osmo-trx-ipc_ will connect to at startup: + +.Example: _osmo-trx-ipc_ will connect to UD Master Socket /tmp/ipc_sock0 upon startup +---- +dev-args ipc_msock=/tmp/ipc_sock0 +---- + +==== ipc-device-test + +When built with `--with-ipc --with-uhd` configure options, _osmo-trx.git_ will build the test program called _ipc-driver-test_. +This program implements the _Driver_ side of the osmo-trx-ipc interface (see <<ipc_if>> for more information) on one side, and also interacts internally with UHD (eg B210 as when using osmo-trx-uhd). + +You can use this small program as a reference to: +* Test and experiment with _osmo-trx-ipc_. +* Write your own IPC _Driver_ connecting to osmo-trx-ipc. + +[[fig-backend-ipc-device-test]] +.Architecture with _osmo-trx-ipc_ and ipc-device-test as IPC _Driver_ +[graphviz] +---- +digraph G { + rankdir=LR; + MS0 [label="MS"]; + MS1 [label="MS"]; + SDR; + ipc_device_test[label = "ipc-device-test", color=red]; + OsmoTRX [label="osmo-trx-ipc", color=red]; + BTS; + + MS0->SDR [label="Um"]; + MS1->SDR [label="Um"]; + SDR->ipc_device_test [label="UHD"]; + ipc_device_test->OsmoTRX [label="IPC Interface", color=red]; + OsmoTRX->BTS [label="bursts over UDP"]; +} +---- + +The code for this app is found here: + +* https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/maste… + +* https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/maste… + +Those files use the server-side (_Driver_ side) code to operate the Posix Shared +Memory region implemented in files `shm.c`, `shm.h`, `ipc_shm.c` and `ipc_shm.h` +in the same directory. + +Most of the code in that same directory is deliverately released under a BSD +license (unlike most of _osmo-trx.git_), allowing third parties to reuse/recycle +the code on their implemented _Driver_ program no matter it being proprietary or +under an open license. However, care must be taken with external dependencies, +as for instance shm.c uses the talloc memory allocator, which is GPL licensed +and hence cannot be used in a proprietary driver. \ No newline at end of file diff --git a/doc/manuals/osmotrx-usermanual.adoc b/doc/manuals/osmotrx-usermanual.adoc index 2d1caad..b768306 100644 --- a/doc/manuals/osmotrx-usermanual.adoc +++ b/doc/manuals/osmotrx-usermanual.adoc @@ -35,6 +35,8 @@ include::./common/chapters/trx_if.adoc[] +include::{srcdir}/chapters/ipc_if.adoc[] + include::./common/chapters/port_numbers.adoc[] include::./common/chapters/bibliography.adoc[] -- To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/36465?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-trx Gerrit-Branch: master Gerrit-Change-Id: Id6863731f9398720030b16efaaf559e05f2444ed Gerrit-Change-Number: 36465 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: newchange

3 months, 1 week

1
0
0 0

[S] Change in osmo-trx[master]: code-architecture.adoc: Fix missing alignment in digraph

by pespin

pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-trx/+/36464?usp=email ) Change subject: code-architecture.adoc: Fix missing alignment in digraph ...................................................................... code-architecture.adoc: Fix missing alignment in digraph Change-Id: I9077590f6786833c9a86c3e844fc2dd07b404d58 --- M doc/manuals/chapters/code-architecture.adoc 1 file changed, 10 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-trx refs/changes/64/36464/1 diff --git a/doc/manuals/chapters/code-architecture.adoc b/doc/manuals/chapters/code-architecture.adoc index f1feb2c..1cb2542 100644 --- a/doc/manuals/chapters/code-architecture.adoc +++ b/doc/manuals/chapters/code-architecture.adoc @@ -9,7 +9,7 @@ node[shape=record,style=filled,fillcolor=gray95] edge[dir=back, arrowtail=empty] -2[label = "{Transceiver|+ constructor()\l+ destructor()\l+ init()\l+ numChans()\l+ receiveFIFO()\l+ setSignalHandler()}"] +2[label = "{Transceiver|+ constructor()\l+ destructor()\l+ init()\l+ numChans()\l+ receiveFIFO()\l+ setSignalHandler()\l}"] 3[label = "{RadioInterface|...}"] 4[label = "{RadioInterfaceResamp|...}"] 5[label = "{RadioInterfaceMulti|...}"] -- To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/36464?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-trx Gerrit-Branch: master Gerrit-Change-Id: I9077590f6786833c9a86c3e844fc2dd07b404d58 Gerrit-Change-Number: 36464 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: newchange

3 months, 1 week

1
0
0 0

[S] Change in docker-playground[master]: ttcn3-bts-test: fix start_config_oml(): do not start BSC

by osmith

osmith has posted comments on this change. ( https://gerrit.osmocom.org/c/docker-playground/+/36462?usp=email ) Change subject: ttcn3-bts-test: fix start_config_oml(): do not start BSC ...................................................................... Patch Set 1: Code-Review+2 (1 comment) Patchset: PS1: thanks! -- To view, visit https://gerrit.osmocom.org/c/docker-playground/+/36462?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: docker-playground Gerrit-Branch: master Gerrit-Change-Id: Iab44b9ed83e917475c9e2e86ad32b303b05b2ace Gerrit-Change-Number: 36462 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 26 Mar 2024 14:43:14 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

3 months, 1 week

1
0
0 0

[S] Change in docker-playground[master]: ttcn3-bts-test: fix start_config_oml(): do not start BSC

by fixeria

fixeria has submitted this change. ( https://gerrit.osmocom.org/c/docker-playground/+/36462?usp=email ) Change subject: ttcn3-bts-test: fix start_config_oml(): do not start BSC ...................................................................... ttcn3-bts-test: fix start_config_oml(): do not start BSC As the comment states, the BSC container is not needed for the OML tests. The testsuite itself "speaks" OML to the IUT in this case. Change-Id: Iab44b9ed83e917475c9e2e86ad32b303b05b2ace Fixes: aad045f5 "ttcn3-bts-test: add env var to not run all configs" Fixes: OS#6421 --- M ttcn3-bts-test/jenkins.sh 1 file changed, 14 insertions(+), 2 deletions(-) Approvals: Jenkins Builder: Verified pespin: Looks good to me, approved laforge: Looks good to me, but someone else must approve diff --git a/ttcn3-bts-test/jenkins.sh b/ttcn3-bts-test/jenkins.sh index ed4ae37..38e3760 100755 --- a/ttcn3-bts-test/jenkins.sh +++ b/ttcn3-bts-test/jenkins.sh @@ -187,7 +187,6 @@ cp oml/osmo-bts.gen.cfg $VOL_BASE_DIR/bts/ network_replace_subnet_in_configs - start_bsc start_bts trx 1 start_fake_trx start_trxcon @@ -197,7 +196,6 @@ docker_kill_wait ${BUILD_TAG}-trxcon docker_kill_wait ${BUILD_TAG}-fake_trx docker_kill_wait ${BUILD_TAG}-bts - docker_kill_wait ${BUILD_TAG}-bsc } # Frequency hopping tests require different configuration files -- To view, visit https://gerrit.osmocom.org/c/docker-playground/+/36462?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: docker-playground Gerrit-Branch: master Gerrit-Change-Id: Iab44b9ed83e917475c9e2e86ad32b303b05b2ace Gerrit-Change-Number: 36462 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: merged

3 months, 1 week

1
0
0 0

2024

2023

2022

gerrit-log March 2024