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

[M] Change in osmo-ttcn3-hacks[master]: library: add generic Mutex API for parallel components

by pespin

Attention is currently required from: fixeria. pespin has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email ) Change subject: library: add generic Mutex API for parallel components ...................................................................... Patch Set 2: (1 comment) File library/Mutex.ttcn: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206/comment/c98fd202_d350… : PS2, Line 19: port MutexPT LOCK; /* port for LOCKing the mutex */ What's the point in having 2 ports instead of 1? Sounds way more complex than it should by doing so, with more race scenarios to think about, more difficult to debug, etc. -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: Id71f43bd5fc78d4bb4417d6c01fcff8112ea6032 Gerrit-Change-Number: 38206 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Fri, 20 Sep 2024 10:18:25 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

9 months, 1 week

1
0
0 0

[S] Change in osmo-ttcn3-hacks[master]: Makefile: avoid fetching deps if not needed

by fixeria

fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38218?usp=email ) Change subject: Makefile: avoid fetching deps if not needed ...................................................................... Makefile: avoid fetching deps if not needed Running `make deps` for the first time fetches all the dependencies. Running `make deps` again currently results in unnecessary git-fetch and get-checkout operations for each dependency. This is not as bad as cloning dependencies from scratch every time, but still takes time and triggers unnecessary requests to the servers. It's also creating problems when building testsuites offline. This patch makes the build system a bit smarter in a way that it would only try to update dependencies if the 'deps/Makefile' was changed. Change-Id: Iae98585f0a83b17596857eba8c2f51a785198580 Related: OS#6572 --- M Makefile 1 file changed, 6 insertions(+), 4 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/18/38218/1 diff --git a/Makefile b/Makefile index 2b806b8..38a8f60 100644 --- a/Makefile +++ b/Makefile @@ -75,14 +75,16 @@ # Eclipse GitLab has rate limiting and sometimes to many concurrent conns fail. # If -jN fails, retry with -j1. -.PHONY: deps -deps: +.make.deps: deps/Makefile ($(MAKE) $(PARALLEL_MAKE) -C deps || $(MAKE) -j1 -C deps) + touch $@ + +.PHONY: deps +deps: .make.deps # deps-update target for backwards compat; now does the same as 'make deps' .PHONY: deps-update -deps-update: - $(MAKE) -C deps +deps-update: .make.deps compile: $(foreach dir,$(SUBDIRS),$(dir)/compile) clean: $(foreach dir,$(SUBDIRS),$(dir)/clean) -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38218?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: Iae98585f0a83b17596857eba8c2f51a785198580 Gerrit-Change-Number: 38218 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>

9 months, 1 week

1
0
0 0

[M] Change in osmo-ttcn3-hacks[master]: s1gw: add multi-eNB variants of TC_e_rab_setup

by fixeria

Hello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38213?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: s1gw: add multi-eNB variants of TC_e_rab_setup ...................................................................... s1gw: add multi-eNB variants of TC_e_rab_setup The idea is to simulate multiple eNBs establishing one or more E-RAB(s) simultaneously. In order to achieve that, use the new Mutex API to ensure that only one ConnHdlr component is triggering PFCP session establishment at any given time. The problem is that there is no way for the PFCPEM component to correlate which PFCP session belongs to which eNB when multiple ConnHdlr instances establish E-RAB(s) in parallel. This can be solved by making a part of the test scenario synchronous. Change-Id: I9e2eb25a7ae78ff623b94802d881af4894d0cacd --- M s1gw/S1GW_ConnHdlr.ttcn M s1gw/S1GW_Tests.ttcn M s1gw/expected-results.xml M s1gw/gen_links.sh 4 files changed, 53 insertions(+), 20 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/13/38213/4 -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38213?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I9e2eb25a7ae78ff623b94802d881af4894d0cacd Gerrit-Change-Number: 38213 Gerrit-PatchSet: 4 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder

9 months, 1 week

1
0
0 0

[M] Change in osmo-ttcn3-hacks[master]: s1gw: add TC_e_rab_release_ind

by fixeria

fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38217?usp=email ) Change subject: s1gw: add TC_e_rab_release_ind ...................................................................... s1gw: add TC_e_rab_release_ind Change-Id: Icc28a596b7646441761cc3f56653c5f7b3ddaaca --- M s1gw/S1GW_ConnHdlr.ttcn M s1gw/S1GW_Tests.ttcn M s1gw/expected-results.xml 3 files changed, 93 insertions(+), 18 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/17/38217/1 diff --git a/s1gw/S1GW_ConnHdlr.ttcn b/s1gw/S1GW_ConnHdlr.ttcn index e4dc35b..493cfd1 100644 --- a/s1gw/S1GW_ConnHdlr.ttcn +++ b/s1gw/S1GW_ConnHdlr.ttcn @@ -394,11 +394,9 @@ return pdu; } -function f_ConnHdlr_tx_erab_release_cmd(in ERabList erabs, - S1AP_IEs.Cause cause := c_REL_CMD_CAUSE, - MME_UE_S1AP_ID mme_ue_id := c_MME_UE_ID) -runs on ConnHdlr { - var ENB_UE_S1AP_ID enb_ue_id := g_pars.idx; +private function f_ts_E_RABList(in ERabList erabs, + S1AP_IEs.Cause cause) +return template (value) E_RABList { var template (value) E_RABList items; for (var integer i := 0; i < lengthof(erabs); i := i + 1) { @@ -408,16 +406,12 @@ items[i] := ts_E_RABList(item)[0]; } - f_ConnHdlr_tx_s1ap_from_mme(ts_S1AP_RABReleaseCmd(mme_ue_id, enb_ue_id, items)); + return items; } - -function f_ConnHdlr_rx_erab_release_cmd(in ERabList erabs, - S1AP_IEs.Cause cause := c_REL_CMD_CAUSE, - MME_UE_S1AP_ID mme_ue_id := c_MME_UE_ID) -runs on ConnHdlr return S1AP_PDU { - var ENB_UE_S1AP_ID enb_ue_id := g_pars.idx; +private function f_tr_E_RABList(in ERabList erabs, + S1AP_IEs.Cause cause) +return template (present) E_RABList { var template (present) E_RABList items; - var S1AP_PDU pdu; for (var integer i := 0; i < lengthof(erabs); i := i + 1) { var template (present) E_RABItem item; @@ -426,10 +420,53 @@ items[i] := tr_E_RABList(item)[0]; } + return items; +} + +function f_ConnHdlr_tx_erab_release_cmd(in ERabList erabs, + S1AP_IEs.Cause cause := c_REL_CMD_CAUSE, + MME_UE_S1AP_ID mme_ue_id := c_MME_UE_ID) +runs on ConnHdlr { + var template (value) E_RABList items := f_ts_E_RABList(erabs, cause); + var ENB_UE_S1AP_ID enb_ue_id := g_pars.idx; + + f_ConnHdlr_tx_s1ap_from_mme(ts_S1AP_RABReleaseCmd(mme_ue_id, enb_ue_id, items)); +} + +function f_ConnHdlr_rx_erab_release_cmd(in ERabList erabs, + S1AP_IEs.Cause cause := c_REL_CMD_CAUSE, + MME_UE_S1AP_ID mme_ue_id := c_MME_UE_ID) +runs on ConnHdlr return S1AP_PDU { + var template (present) E_RABList items := f_tr_E_RABList(erabs, cause); + var ENB_UE_S1AP_ID enb_ue_id := g_pars.idx; + var S1AP_PDU pdu; + f_ConnHdlr_rx_s1ap_from_mme(pdu, tr_S1AP_RABReleaseCmd(mme_ue_id, enb_ue_id, items)); return pdu; } +function f_ConnHdlr_tx_erab_release_ind(in ERabList erabs, + S1AP_IEs.Cause cause := c_REL_CMD_CAUSE, + MME_UE_S1AP_ID mme_ue_id := c_MME_UE_ID) +runs on ConnHdlr { + var template (value) E_RABList items := f_ts_E_RABList(erabs, cause); + var ENB_UE_S1AP_ID enb_ue_id := g_pars.idx; + + f_ConnHdlr_tx_s1ap_from_enb(ts_S1AP_RABReleaseInd(mme_ue_id, enb_ue_id, items)); +} + +function f_ConnHdlr_rx_erab_release_ind(in ERabList erabs, + S1AP_IEs.Cause cause := c_REL_CMD_CAUSE, + MME_UE_S1AP_ID mme_ue_id := c_MME_UE_ID) +runs on ConnHdlr return S1AP_PDU { + var template (present) E_RABList items := f_tr_E_RABList(erabs, cause); + var ENB_UE_S1AP_ID enb_ue_id := g_pars.idx; + var S1AP_PDU pdu; + + f_ConnHdlr_rx_s1ap_from_enb(pdu, tr_S1AP_RABReleaseInd(mme_ue_id, enb_ue_id, items)); + return pdu; +} + function f_ConnHdlr_rx_session_establish_req(in ERab erab) runs on ConnHdlr return PDU_PFCP { var OCT4 addr := f_inet_addr(g_pars.pfcp_rem_addr); @@ -604,10 +641,8 @@ f_ConnHdlr_rx_erab_setup_rsp(erabs); } -function f_ConnHdlr_erab_release_cmd(inout ERabList erabs, - S1AP_IEs.Cause cause := c_REL_CMD_CAUSE) +private function f_ConnHdlr_session_delete(inout ERabList erabs) runs on ConnHdlr { - f_ConnHdlr_tx_erab_release_cmd(erabs, cause); for (var integer i := 0; i < lengthof(erabs); i := i + 1) { log("UPF <- S1GW: PFCP Session Deletion Request for E-RAB ID ", erabs[i].erab_id); var PDU_PFCP pdu := f_ConnHdlr_rx_session_delete_req(erabs[i]); @@ -616,7 +651,22 @@ /* ask PFCPEM to *not* route PDUs with this SEID to us */ f_PFCPEM_unsubscribe_seid(erabs[i].pfcp_loc_seid); } +} + +function f_ConnHdlr_erab_release_cmd(inout ERabList erabs, + S1AP_IEs.Cause cause := c_REL_CMD_CAUSE) +runs on ConnHdlr { + f_ConnHdlr_tx_erab_release_cmd(erabs, cause); + f_ConnHdlr_session_delete(erabs); f_ConnHdlr_rx_erab_release_cmd(erabs, cause); } +function f_ConnHdlr_erab_release_ind(inout ERabList erabs, + S1AP_IEs.Cause cause := c_REL_CMD_CAUSE) +runs on ConnHdlr { + f_ConnHdlr_tx_erab_release_ind(erabs, cause); + f_ConnHdlr_session_delete(erabs); + f_ConnHdlr_rx_erab_release_ind(erabs, cause); +} + } diff --git a/s1gw/S1GW_Tests.ttcn b/s1gw/S1GW_Tests.ttcn index c5ff7c4..362407f 100644 --- a/s1gw/S1GW_Tests.ttcn +++ b/s1gw/S1GW_Tests.ttcn @@ -299,7 +299,7 @@ vc_conn.done; } -/* Test E-RAB SETUP [and RELEASE] procedures */ +/* Test E-RAB SETUP and RELEASE.cmd procedures */ function f_TC_e_rab_setup(charstring id) runs on ConnHdlr { f_ConnHdlr_s1ap_register(g_pars.genb_id); f_ConnHdlr_s1ap_connect(mp_enb_bind_ip, mp_s1gw_enb_ip); @@ -342,6 +342,29 @@ f_TC_e_rab_setup_exec(num_enbs := mp_multi_enb_num, num_erabs := 3); } +/* Test E-RAB SETUP and RELEASE.ind procedures */ +function f_TC_e_rab_release_ind(charstring id) runs on ConnHdlr { + f_ConnHdlr_s1ap_register(g_pars.genb_id); + f_ConnHdlr_s1ap_connect(mp_enb_bind_ip, mp_s1gw_enb_ip); + f_ConnHdlr_s1ap_setup(g_pars.genb_id); + + f_ConnHdlr_erab_setup_req(g_pars.erabs); + f_ConnHdlr_erab_setup_rsp(g_pars.erabs); + f_ConnHdlr_erab_release_ind(g_pars.erabs); + + f_ConnHdlr_s1ap_disconnect(); + f_ConnHdlr_s1ap_unregister(g_pars.genb_id); +} +testcase TC_e_rab_release_ind() runs on test_CT { + var ConnHdlrPars pars := valueof(t_ConnHdlrPars); + var ConnHdlr vc_conn; + + f_init(); + + vc_conn := f_ConnHdlr_spawn(refers(f_TC_e_rab_release_ind), pars); + vc_conn.done; +} + function f_TC_pfcp_heartbeat(charstring id) runs on ConnHdlr { var integer rts := f_PFCPEM_get_recovery_timestamp(); var PDU_PFCP pfcp_pdu; @@ -374,6 +397,7 @@ execute( TC_e_rab_setup3() ); execute( TC_e_rab_setup_multi() ); execute( TC_e_rab_setup3_multi() ); + execute( TC_e_rab_release_ind() ); execute( TC_pfcp_heartbeat() ); } diff --git a/s1gw/expected-results.xml b/s1gw/expected-results.xml index 99a75d5..9075dc3 100644 --- a/s1gw/expected-results.xml +++ b/s1gw/expected-results.xml @@ -1,5 +1,5 @@ <?xml version="1.0"?> -<testsuite name='S1GW_Tests' tests='9' failures='0' errors='0' skipped='0' inconc='0' time='MASKED'> +<testsuite name='S1GW_Tests' tests='10' failures='0' errors='0' skipped='0' inconc='0' time='MASKED'> <testcase classname='S1GW_Tests' name='TC_setup' time='MASKED'/> <testcase classname='S1GW_Tests' name='TC_setup_multi' time='MASKED'/> <testcase classname='S1GW_Tests' name='TC_conn_term_by_mme' time='MASKED'/> @@ -8,5 +8,6 @@ <testcase classname='S1GW_Tests' name='TC_e_rab_setup3' time='MASKED'/> <testcase classname='S1GW_Tests' name='TC_e_rab_setup_multi' time='MASKED'/> <testcase classname='S1GW_Tests' name='TC_e_rab_setup3_multi' time='MASKED'/> + <testcase classname='S1GW_Tests' name='TC_e_rab_release_ind' time='MASKED'/> <testcase classname='S1GW_Tests' name='TC_pfcp_heartbeat' time='MASKED'/> </testsuite> -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38217?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: Icc28a596b7646441761cc3f56653c5f7b3ddaaca Gerrit-Change-Number: 38217 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>

9 months, 1 week

1
0
0 0

[XS] Change in osmo-ttcn3-hacks[master]: s1gw: f_ConnHdlr_rx_erab_release_cmd(): fix wrong template

by fixeria

fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38216?usp=email ) Change subject: s1gw: f_ConnHdlr_rx_erab_release_cmd(): fix wrong template ...................................................................... s1gw: f_ConnHdlr_rx_erab_release_cmd(): fix wrong template Change-Id: Ib6b9f346216aaa9587025e1c580876611e6fa7bc --- M s1gw/S1GW_ConnHdlr.ttcn 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/16/38216/1 diff --git a/s1gw/S1GW_ConnHdlr.ttcn b/s1gw/S1GW_ConnHdlr.ttcn index 2833ce1..e4dc35b 100644 --- a/s1gw/S1GW_ConnHdlr.ttcn +++ b/s1gw/S1GW_ConnHdlr.ttcn @@ -422,7 +422,7 @@ for (var integer i := 0; i < lengthof(erabs); i := i + 1) { var template (present) E_RABItem item; - item := ts_E_RABItem(erabs[i].erab_id, cause); + item := tr_E_RABItem(erabs[i].erab_id, cause); items[i] := tr_E_RABList(item)[0]; } -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38216?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: Ib6b9f346216aaa9587025e1c580876611e6fa7bc Gerrit-Change-Number: 38216 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>

9 months, 1 week

1
0
0 0

[S] Change in osmo-ttcn3-hacks[master]: s1gw: move PFCP association handling into a dedicated ConnHdlr

by fixeria

Attention is currently required from: fixeria. Hello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38212?usp=email to look at the new patch set (#3). The following approvals got outdated and were removed: Verified-1 by Jenkins Builder Change subject: s1gw: move PFCP association handling into a dedicated ConnHdlr ...................................................................... s1gw: move PFCP association handling into a dedicated ConnHdlr Previously, the PFCP association request from the IUT was handled by the first ConnHdlr component (idx := 0). While this approach has worked, it fails when multiple ConnHdlr instances (idx > 0) are spawned. The problem arises when other ConnHdlr (idx > 0) instances initiate PFCP procedures before the first ConnHdlr (idx := 0) has established the association, so we end up playing races. This patch introduces a dedicated ConnHdlr component to handle the PFCP association independently. Once the association is established, the actual test ConnHdlr instances are spawned, ensuring a more reliable and orderly process. Change-Id: I5e1a14105a35b785bf598dc2a8c436ea6fb6b0f1 --- M s1gw/S1GW_ConnHdlr.ttcn M s1gw/S1GW_Tests.ttcn 2 files changed, 22 insertions(+), 20 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/12/38212/3 -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38212?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I5e1a14105a35b785bf598dc2a8c436ea6fb6b0f1 Gerrit-Change-Number: 38212 Gerrit-PatchSet: 3 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>

9 months, 1 week

1
0
0 0

[S] Change in ...osmo-s1gw[master]: pfcp_peer: do not assign SEID=0, increment properly

by fixeria

fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/38215?usp=email ) Change subject: pfcp_peer: do not assign SEID=0, increment properly ...................................................................... pfcp_peer: do not assign SEID=0, increment properly Change-Id: I76b921047784e727d67cd6c6a5aeb6d827b65e56 --- M src/pfcp_peer.erl 1 file changed, 9 insertions(+), 3 deletions(-) git pull ssh://gerrit.osmocom.org:29418/erlang/osmo-s1gw refs/changes/15/38215/1 diff --git a/src/pfcp_peer.erl b/src/pfcp_peer.erl index f379e69..aa33e3a 100644 --- a/src/pfcp_peer.erl +++ b/src/pfcp_peer.erl @@ -54,11 +54,13 @@ %% 3GPP TS 29.244, section 4.2 "UDP Header and Port Numbers" -define(PFCP_PORT, 8805). +-define(PFCP_SEID_MAX, 16#ffffffffffffffff). + -type pfcp_session_rsp() :: ok | {error, term()}. -type pfcp_msg_type() :: atom(). -type pfcp_seq_nr() :: 0..16#ffffff. --type pfcp_seid() :: 0..16#ffffffffffffffff. +-type pfcp_seid() :: 0..?PFCP_SEID_MAX. -type pfcp_f_seid() :: #f_seid{}. -type pfcp_ies() :: [term()] | map() | binary(). -type pfcp_msg() :: {pfcp_msg_type(), pfcp_ies()}. @@ -139,7 +141,7 @@ {reuseaddr, true}, {active, true}]), ?LOG_INFO("PFCP peer @ ~p will talk to UPF @ ~p", [LocAddr, RemAddr]), - {ok, connecting, #peer_state{seid = 0, + {ok, connecting, #peer_state{seid = 1, %% SEID=0 is special, see 7.2.2.4.2 sock = Sock, loc_addr = LocAddr, rem_addr = RemAddr, @@ -288,8 +290,12 @@ Ref = erlang:monitor(process, Pid), NReg = dict:store(SEID, {Pid, Ref}, Reg), ?LOG_DEBUG("Allocated SEID ~p to process ~p", [SEID, Pid]), + NSEID = case SEID of + ?PFCP_SEID_MAX -> 1; + _ -> SEID + 1 + end, S#peer_state{registry = NReg, - seid = SEID + 1}. + seid = NSEID}. -spec registry_del({pid(), reference()}, peer_state()) -> peer_state(). -- To view, visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/38215?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: erlang/osmo-s1gw Gerrit-Branch: master Gerrit-Change-Id: I76b921047784e727d67cd6c6a5aeb6d827b65e56 Gerrit-Change-Number: 38215 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>

9 months, 1 week

1
0
0 0

[L] Change in osmo-ttcn3-hacks[master]: library/PFCP_Emulation: a better PDU routing concept

by fixeria

fixeria has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38207?usp=email ) Change subject: library/PFCP_Emulation: a better PDU routing concept ...................................................................... Set Ready For Review -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38207?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I25802471519fa297ad4cb2b056adaa6748b00af2 Gerrit-Change-Number: 38207 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Comment-Date: Thu, 19 Sep 2024 19:33:21 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No

9 months, 1 week

1
0
0 0

[M] Change in osmo-ttcn3-hacks[master]: library: add generic Mutex API for parallel components

by fixeria

Hello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email to look at the new patch set (#2). Change subject: library: add generic Mutex API for parallel components ...................................................................... library: add generic Mutex API for parallel components In certain scenarios, it's required to ensure that only one of multiple parallel components executes a specific code block at any given time. This, for example, is the case for the S1GW testsuite, where we want to simulate multiple eNBs establishing E-RABs. Each new E-RAB triggers the IUT (osmo-s1gw) to send a PFCP Session Establishment Request, and there is no way for the PFCPEM to correlate which session belongs to which eNB. This problem can be solved by ensuring that only one eNB is triggering the PFCP Session Establishment Request(s) at a time. This patch implements a generic Mutex API, which can also be used by other testsuites that orchestrate multiple parallel components. Change-Id: Id71f43bd5fc78d4bb4417d6c01fcff8112ea6032 --- A library/Mutex.ttcn 1 file changed, 135 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/06/38206/2 -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: Id71f43bd5fc78d4bb4417d6c01fcff8112ea6032 Gerrit-Change-Number: 38206 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder

9 months, 1 week

1
0
0 0

[M] Change in osmo-ttcn3-hacks[master]: library: add generic Mutex API for parallel components

by fixeria

fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email ) Change subject: library: add generic Mutex API for parallel components ...................................................................... library: add generic Mutex API for parallel components In certain scenarios, it's required to ensure that only one of multiple parallel components executes a specific code block at any given time. This, for example, is the case for the S1GW testsuite, where we want to simulate multiple eNBs establishing E-RABs. Each E-RAB triggers the IUT (osmo-s1gw) to send a PFCP Session Establishment Request, and there is currently no way to correlate which session belongs to which eNB. This problem can be solved by ensuring that only one eNB is triggering the PFCP Session Establishment Request(s) at a time. This patch implements a generic Mutex API, which can also be used by other testsuites that orchestrate multiple parallel components. Change-Id: Id71f43bd5fc78d4bb4417d6c01fcff8112ea6032 --- A library/Mutex.ttcn 1 file changed, 135 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/06/38206/1 diff --git a/library/Mutex.ttcn b/library/Mutex.ttcn new file mode 100644 index 0000000..625090b --- /dev/null +++ b/library/Mutex.ttcn @@ -0,0 +1,135 @@ +/* Generic Mutex API for parallel components. + * + * (C) 2024 by sysmocom - s.f.m.c. GmbH <info(a)sysmocom.de> + * Author: Vadim Yanitskiy <vyanitskiy(a)sysmocom.de> + * + * All rights reserved. + * + * Released under the terms of GNU General Public License, Version 2 or + * (at your option) any later version. + * + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +module Mutex { + +import from Misc_Helpers all; + +type component MutexCT { + port MutexPT LOCK; /* port for LOCKing the mutex */ + port MutexPT UNLOCK; /* port for UNLOCKing the mutex */ + var integer g_mutex_ref; +}; + +type port MutexPT procedure { + inout MUTEX_LOCK; + inout MUTEX_UNLOCK; +} with { extension "internal" }; + +private signature MUTEX_LOCK(out integer ref); +private signature MUTEX_UNLOCK(in integer ref) noblock; + +type component MutexDispCT extends MutexCT { }; + +private function f_MutexDisp_main() +runs on MutexDispCT { + var boolean locked := false; + var MutexCT vc_conn; + + g_mutex_ref := 0; + + alt { + [not locked] LOCK.getcall(MUTEX_LOCK:{?}) -> sender vc_conn { + LOCK.reply(MUTEX_LOCK:{g_mutex_ref}) to vc_conn; + locked := true; + repeat; + } + [locked] UNLOCK.getcall(MUTEX_UNLOCK:{g_mutex_ref}) { + g_mutex_ref := g_mutex_ref + 1; + locked := false; + repeat; + } + [not locked] UNLOCK.getcall -> sender vc_conn { + setverdict(fail, __SCOPE__, "(): ", + "mutex unlock without prior lock from ", vc_conn); + Misc_Helpers.f_shutdown(__BFILE__, __LINE__); + } + [locked] UNLOCK.getcall(MUTEX_UNLOCK:{?}) -> sender vc_conn { + setverdict(fail, __SCOPE__, "(): ", + "mutex unlock was not unexpected from ", vc_conn); + Misc_Helpers.f_shutdown(__BFILE__, __LINE__); + } + } +} + +/* used by the MTC to start the mutex dispatcher */ +function f_MutexDisp_start() +return MutexDispCT { + var MutexDispCT vc_disp; + + vc_disp := MutexDispCT.create("MutexDispCT-" & testcasename()); + vc_disp.start(f_MutexDisp_main()); + + return vc_disp; +} + +/* used by the MTC to connect a parallel component to the mutex dispatcher */ +function f_MutexDisp_connect(MutexDispCT vc_disp, MutexCT vc_conn) +{ + connect(vc_disp:LOCK, vc_conn:LOCK); + connect(vc_disp:UNLOCK, vc_conn:UNLOCK); +} + +/* used by parallel components to lock the mutex (blocking) */ +function f_Mutex_lock(charstring file, integer line, + float Tval := 10.0) +runs on MutexCT { + LOCK.call(MUTEX_LOCK:{-}, Tval) { + [] LOCK.getreply(MUTEX_LOCK:{?}) -> param(g_mutex_ref) { + log(__SCOPE__, "(): mutex acquired @ ", file, ":", line); + } + [] LOCK.catch(timeout) { + setverdict(fail, __SCOPE__, "(): timeout @ ", file, ":", line); + Misc_Helpers.f_shutdown(file, line); + } + } +} + +/* used by parallel components to unlock the mutex (non-blocking) */ +function f_Mutex_unlock(charstring file, integer line) +runs on MutexCT { + UNLOCK.call(MUTEX_UNLOCK:{g_mutex_ref}); + log(__SCOPE__, "(): mutex released @ ", file, ":", line); +} + + +/* self-test for this module */ +private type component TestCT { }; +private type component TestChildCT extends MutexCT { }; + +private function f_TC_selftest() +runs on TestChildCT { + f_Mutex_lock(__BFILE__, __LINE__); + /* yay, we're the only one ruling this parallel world! */ + f_Mutex_unlock(__BFILE__, __LINE__); + setverdict(pass); +} + +testcase TC_selftest() runs on TestCT { + var TestChildCT vc_conns[42]; + var MutexDispCT vc_disp; + + vc_disp := f_MutexDisp_start(); + + for (var integer i := 0; i < sizeof(vc_conns); i := i + 1) { + vc_conns[i] := TestChildCT.create("TestChildCT-" & int2str(i)); + f_MutexDisp_connect(vc_disp, vc_conns[i]); + vc_conns[i].start(f_TC_selftest()); + } + + for (var integer i := 0; i < sizeof(vc_conns); i := i + 1) { + vc_conns[i].done; + } +} + +} -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: Id71f43bd5fc78d4bb4417d6c01fcff8112ea6032 Gerrit-Change-Number: 38206 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>

9 months, 1 week

1
0
0 0

2025

2024

2023

2022

gerrit-log September 2024