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

[S] Change in osmo-upf[master]: manual: 'Running': tweak word, fix ws at line end

by neels

neels has uploaded a new patch set (#2). ( https://gerrit.osmocom.org/c/osmo-upf/+/36557?usp=email ) Change subject: manual: 'Running': tweak word, fix ws at line end ...................................................................... manual: 'Running': tweak word, fix ws at line end Change-Id: Id9a4d2d75f86a252df0da6e7e0ae5ab47e8a7bf9 --- M doc/manuals/chapters/running.adoc 1 file changed, 10 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-upf refs/changes/57/36557/2 -- To view, visit https://gerrit.osmocom.org/c/osmo-upf/+/36557?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-upf Gerrit-Branch: master Gerrit-Change-Id: Id9a4d2d75f86a252df0da6e7e0ae5ab47e8a7bf9 Gerrit-Change-Number: 36557 Gerrit-PatchSet: 2 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-CC: Jenkins Builder Gerrit-MessageType: newpatchset

1 year, 2 months

1
0
0 0

[S] Change in osmo-upf[master]: manual: 'Running': tweak, word, fix ws at line end

by neels

neels has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-upf/+/36557?usp=email ) Change subject: manual: 'Running': tweak, word, fix ws at line end ...................................................................... manual: 'Running': tweak, word, fix ws at line end Change-Id: Id9a4d2d75f86a252df0da6e7e0ae5ab47e8a7bf9 --- M doc/manuals/chapters/running.adoc 1 file changed, 10 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-upf refs/changes/57/36557/1 diff --git a/doc/manuals/chapters/running.adoc b/doc/manuals/chapters/running.adoc index 009ec16..8e1d5ee 100644 --- a/doc/manuals/chapters/running.adoc +++ b/doc/manuals/chapters/running.adoc @@ -88,7 +88,7 @@ * The GTP module is used for `tunend`: GTP encapsulation/decapsulation from/to "the internet". -* The netfilter framework and nftables is used for `tunmap`: GTP tunnel proxying, +* The netfilter framework and nftables are used for `tunmap`: GTP tunnel proxying, also known as tunnel forwarding or tunnel mapping. .Linux kernel feature usage -- To view, visit https://gerrit.osmocom.org/c/osmo-upf/+/36557?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-upf Gerrit-Branch: master Gerrit-Change-Id: Id9a4d2d75f86a252df0da6e7e0ae5ab47e8a7bf9 Gerrit-Change-Number: 36557 Gerrit-PatchSet: 1 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-MessageType: newchange

1 year, 2 months

1
0
0 0

[M] Change in osmo-upf[master]: manual: explain GTP Echo workaround for tunmap

by neels

Attention is currently required from: neels. Hello Jenkins Builder, laforge, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-upf/+/35667?usp=email to look at the new patch set (#2). The following approvals got outdated and were removed: Verified+1 by Jenkins Builder Change subject: manual: explain GTP Echo workaround for tunmap ...................................................................... manual: explain GTP Echo workaround for tunmap Change-Id: Ic824fc876d1fad181254cb6894e51464c443b53c --- M doc/manuals/chapters/running.adoc 1 file changed, 62 insertions(+), 7 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-upf refs/changes/67/35667/2 -- To view, visit https://gerrit.osmocom.org/c/osmo-upf/+/35667?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-upf Gerrit-Branch: master Gerrit-Change-Id: Ic824fc876d1fad181254cb6894e51464c443b53c Gerrit-Change-Number: 35667 Gerrit-PatchSet: 2 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-MessageType: newpatchset

1 year, 2 months

1
0
0 0

[M] Change in libosmocore[master]: add osmo_stats_report_lock api

by neels

Attention is currently required from: fixeria, laforge, pespin. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/36538?usp=email ) Change subject: add osmo_stats_report_lock api ...................................................................... Patch Set 3: (1 comment) Patchset: PS3: (BTW, I updated the commit log message to highlight that it's about keeping separate counters in sync with each other) -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/36538?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: Ib335bea7d2a440ca284e6c439066f96456bf2c2d Gerrit-Change-Number: 36538 Gerrit-PatchSet: 3 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Sat, 13 Apr 2024 00:09:01 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 year, 2 months

1
0
0 0

[M] Change in libosmocore[master]: add osmo_stats_report_lock api

by neels

Attention is currently required from: fixeria, laforge, pespin. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/36538?usp=email ) Change subject: add osmo_stats_report_lock api ...................................................................... Patch Set 3: (1 comment) Patchset: PS2: > > pespin says use intermediate storage with mutexes in a comment at https://gerrit.osmocom. […] let's get back to libosmocore and this patch, the particular lock/unlock discussion belongs to whichever patch is using this new API. (here in particular: https://gerrit.osmocom.org/c/osmo-hnbgw/+/36540 -- see there for a response on above points.) The important point here is, quoting: A mutex lock around stats reporting is a very basic and very powerful tool. It allows a multi-threaded application to decide which stats updates will always be in sync. -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/36538?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: Ib335bea7d2a440ca284e6c439066f96456bf2c2d Gerrit-Change-Number: 36538 Gerrit-PatchSet: 3 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Sat, 13 Apr 2024 00:03:47 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de> Comment-In-Reply-To: laforge <laforge(a)osmocom.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: comment

1 year, 2 months

1
0
0 0

[M] Change in libosmocore[master]: add osmo_stats_report_lock api

by neels

Attention is currently required from: fixeria, laforge, neels. Hello Jenkins Builder, fixeria, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/libosmocore/+/36538?usp=email to look at the new patch set (#3). Change subject: add osmo_stats_report_lock api ...................................................................... add osmo_stats_report_lock api Allow multi-threaded access to reported stats: - enable use of a stats mutex with osmo_stats_report_use_lock(true). - lock/unlock externally with osmo_stats_report_lock(true/false). Rationale: A mutex lock around stats reporting is a very basic and very powerful tool. It allows a multi-threaded application to decide which stats updates will always be in sync. For example, what if the main thread reports rate counters at exactly the time a second thread updates rate counter values? - is writing to stats atomic on a data type level? - do applications need stats to be "atomic" as a whole? We probably have (or can make) int64_t atomic, so that individual counters will always be reported correctly. But often, separate stats correspond to each other, which should not be reported out of sync with each other. The simplest way to manage stats sync in all cases is a mutex around the stats reporting. But such a mutex isn't needed in most programs, with stats happening in a single thread only. To completely avoid any overhead the mutex may bring, make using a mutex optional with a global flag. Related: SYS#6773 Related: osmo-hnbgw I9dc54e6bc94c553f45adfa71ae8ad70be4afbc8f Change-Id: Ib335bea7d2a440ca284e6c439066f96456bf2c2d --- M include/osmocom/core/stats.h M src/core/libosmocore.map M src/core/stats.c M src/vty/stats_vty.c 4 files changed, 126 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/38/36538/3 -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/36538?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: Ib335bea7d2a440ca284e6c439066f96456bf2c2d Gerrit-Change-Number: 36538 Gerrit-PatchSet: 3 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-MessageType: newpatchset

1 year, 2 months

1
0
0 0

[M] Change in osmo-hnbgw[master]: nft_kpi: retrieve counters in a separate thread

by neels

neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/36540?usp=email ) Change subject: nft_kpi: retrieve counters in a separate thread ...................................................................... Patch Set 3: (1 comment) Patchset: PS3: Quoting from the "Depends" libosmocore patch discussion: > For this one, my aim was to say that osmo-trx is doing it that way, not that you > should do it that way. oh, misunderstanding. > If you plan on keep the mutex locked while you gather counters from nft in this patch: the stats lock is held while updating the rate_ctrs only, locking only *after* the nft command has run and returned the complete response in a char buffer. I expect running through that buffer to be very fast, so i lock stats reporting once all around the buffer parsing. If it turns out wrong, we can unlock and re-lock the mutex after every N items (or every N ms?), which would remove "all" blocking of stats. (It is important to keep counters for each HNB in sync, but not important to keep HNBs in sync with each other.) I expect buffer parsing to already be imperceptibly fast; this is O(n) of pure pointer arithmetic, no syscalls. > most probably blocking the main thread also for the same amount of time. (I've written this before in different places, but allow me to re-post, to make sure it is mentioned here:) Blocking of the main thread can happen with this patch, at the times when the main thread wants to run a quick nft command. This happens only at HNBAP HNB Register and Deregister, i.e. when a hNodeB shows up or disappears; to set up / remove nft counter rules. Here the main thread may have to wait for the second thread querying the counters from nftables. There is an ascii art of it in this patch. To circumvent this blocking, an inter-thread queue can be introduced to tell the second thread to carry out the nft commands the main thread wants to run. This is not implemented in this patch on purpose, because: The HNB Register / Deregister are rare events, and reading counters doesn't really take all that long, either. It may well turn out to be overkill to even have a thread for nftables in the first place. It is slow for large numbers of items, but counters for under 1000 HNB from nft should be fast. -- To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/36540?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-hnbgw Gerrit-Branch: master Gerrit-Change-Id: I9dc54e6bc94c553f45adfa71ae8ad70be4afbc8f Gerrit-Change-Number: 36540 Gerrit-PatchSet: 3 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Comment-Date: Fri, 12 Apr 2024 23:53:48 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 year, 2 months

1
0
0 0

[S] Change in osmo-ttcn3-hacks[master]: msc: expand TC_lu_tmsi_noauth_notmsi

by neels

Attention is currently required from: fixeria, laforge, pespin. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36460?usp=email ) Change subject: msc: expand TC_lu_tmsi_noauth_notmsi ...................................................................... Patch Set 2: Code-Review+2 (2 comments) Patchset: PS2: combine votes File msc/MSC_Tests.ttcn: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36460/comment/1f82b37e_a446… PS1, Line 7324: f_cl3_or_initial_ue(valueof(ts_PAG_RESP(ts_MI_IMSI_LV(pars.imsi)))); > This can turn out pretty substantial effort: when working on ttcn3, I do not want to adjust API ever […] i agree with the point, but would like to keep it separate from this patch, so resolving in this context here -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36460?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: I5e596597add7d585efd27c850067b8d7ba34ecc0 Gerrit-Change-Number: 36460 Gerrit-PatchSet: 2 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Fri, 12 Apr 2024 23:15:31 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: comment

1 year, 2 months

1
0
0 0

[M] Change in osmo-ttcn3-hacks[master]: msc: add TC_lu_tmsi_noauth_notmsi

by neels

Attention is currently required from: fixeria. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36459?usp=email ) Change subject: msc: add TC_lu_tmsi_noauth_notmsi ...................................................................... Patch Set 2: Code-Review+2 (1 comment) Patchset: PS2: combining votes -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36459?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: If10b9987395670b084ff8ad6d1f033ff46896d75 Gerrit-Change-Number: 36459 Gerrit-PatchSet: 2 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Fri, 12 Apr 2024 23:11:19 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 year, 2 months

1
0
0 0

[S] Change in osmo-ttcn3-hacks[master]: msc: rework f_expect_paging(): handle mismatch and timeout

by neels

Attention is currently required from: fixeria. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36456?usp=email ) Change subject: msc: rework f_expect_paging(): handle mismatch and timeout ...................................................................... Patch Set 2: Code-Review+1 (3 comments) Commit Message: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36456/comment/f63f9f89_71e0… PS2, Line 13: you could add Tweaked-by: fixeria File msc/BSC_ConnectionHandler.ttcn: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36456/comment/27c67875_d1c3… PS2, Line 1362: [g_pars.ran_is_geran] BSSAP.receive(tr_BSSMAP_Paging(g_pars.imsi, tmsi)); (again the weird mix of g_pars.imsi vs not-g_pars tmsi) https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36456/comment/c8f8d22d_c3cb… PS2, Line 1366: function f_expect_paging(template OCT4 tmsi := *, float Tval := 4.0) it would be very elegant if we could have the mechanism that {expects a message, but fails on a different one, and has a timeout} in a more general function, i.e. not specialized for paging in particluar. Then feed a paging PDU template to that. Then we can use this generalized function all over MSC_Tests. We have such in HNBGW_Tests.ttcn, like f_rua_expect() f_bssap_expect() Would that work here? AFAICT we need a separate function for each port-type x PDU-type combination, but not for each message type? my motivation is for a more generalized approach so that the discussions we had in CR don't come up so much... -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36456?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: I30273e3882e348a2ded88b7b96a5ec1473a56913 Gerrit-Change-Number: 36456 Gerrit-PatchSet: 2 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Fri, 12 Apr 2024 23:08:44 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 year, 2 months

1
0
0 0

2025

2024

2023

2022

gerrit-log April 2024