Attention is currently required from: laforge, neels.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539?usp=email )
Change subject: per-HNB GTP-U traffic counters via nft
......................................................................
Patch Set 9:
(16 comments)
File include/osmocom/hnbgw/hnbgw.h:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/84344d4d_b07e3a98
PS6, Line 384: /* When rules to count traffic to and from this hNodeB are present, this reflects the state in nftables
> Done
ACK.
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/ac15f67a_9120ed54
PS6, Line 394: struct osmo_sockaddr_str addr_remote;
> libnftables interfacing is string based, as the patch should show in other places
Done
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/f00243b2_56949943
PS6, Line 402: struct {
> (in an earlier patch set i actually had the two combined in one struct.) […]
Oh I didn't mean joining the dl and ul. My proposal was to simply make the struct named so it can be declared one, used twice. That also makes it possible to pass a pointer to it.
File include/osmocom/hnbgw/nft_kpi.h:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/2d63fa0a_4f91520d
PS6, Line 21: int nft_kpi_hnb_start(struct hnb_persistent *hnbp, const struct osmo_sockaddr_str *gtpu_remote);
> nftables uses strings (also all logging), so it makes sense to use strings here. […]
Done
File src/osmo-hnbgw/hnbgw.c:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/09ce5455_93fb3768
PS6, Line 346: hnb_persistent_disconnected(ctx->persistent);
> (or "active" and "inactive", s.a. […]
Yeah, whatever, just give it a second though :)
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/d495300f_44ccb1b7
PS6, Line 607: {
> exactly what i mean above. But this patch is not about fixing the HNBAP / HNB activity tracking. […]
Ack
File src/osmo-hnbgw/hnbgw_hnbap.c:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/2b5a2a59_fccd98c0
PS6, Line 571: hnb_persistent_connected(ctx->persistent);
> yes, but how osmo-hnbgw handles HNBAP is weird. […]
Can actually an HNB be registered without being connected? I don't think so.
My understanding is that a HNBAP link disconnect makes the HNB implicitly become "unregistered".
File src/osmo-hnbgw/hnbgw_vty.c:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/f3192d20_704f761c
PS6, Line 884: DEFUN(cfg_hnbgw_nft_kpi, cfg_hnbgw_nft_kpi_cmd,
> I wanted to, but it does not exist AFAICT: […]
Ah then it's probably the default. DONE.
File src/osmo-hnbgw/nft_kpi.c:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/7fd077cd_6b1f1569
PS6, Line 86: static __thread struct nft_thread *g_nft_thread = NULL;
> the nft_thread could be launched any number of times. […]
Ok, I'm not really a fan of having this sort of generic thread which may or may not do stuff, makes the architecture more open for no good reason, but fine.
I'd prefer having 2 (actually 3 counting the main thread) distinct threads doing specific stuff with specific context, but if you like it the other way we can keep it.
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/16d564ff_9dfe2e27
PS6, Line 120: LOGP(DNFT, LOGL_ERROR, "error running nft cmd %s#%u: rc=%d cmd=%s\n",
> yes we have the rc that is carried back to the main thread in the queued response. […]
Done
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/9c8b547a_5f808d31
PS6, Line 182: enum nft_thread_req_type {
> can, but this is the part of the file that defines the thread request queue, so i'd like this to be […]
Done
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/68d34dcd_2c071dcd
PS6, Line 207: struct {
> hence the naming yes
Done
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/7ade3ea8_0eef8f10
PS6, Line 251: OSMO_ASSERT(g_nft_thread);
> Why allocate it using talloc? […]
Done
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/6601dced_9cada900
PS6, Line 297: static void nft_t2m_enqueue(struct nft_thread *t, struct nft_thread_req *req)
> The terms I use so far are "main()" and "(nft-)thread", because main() isn't started by pthread_crea […]
Done
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/0e333f77_964f8f30
PS6, Line 415: static int update_ctr(struct rate_ctr_group *cg, int cgidx, uint64_t *last_val, uint64_t new_val)
> but the second thought made you realize that there is a cg counter group involved, right =)
Yes, after looking at the surrounding code. Just sharing that we use "ctrg" in lots of places already, so it's easier for osmocom users to understand right away.
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539/comment/27662d54_da2b328d
PS6, Line 452: size_t want = g_nft_thread->counters_len + 64;
> I used \*2 in an array list for a diff algorithm implementation in the https://gameoftrees. […]
Done
--
To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/36539?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: Ib2f0a9252715ea4b2fe9c367aa65f771357768ca
Gerrit-Change-Number: 36539
Gerrit-PatchSet: 9
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Wed, 22 May 2024 09:20:51 +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
Attention is currently required from: laforge.
osmith has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/36788?usp=email )
Change subject: KPI: Add initial set of DTAP message type rate counters
......................................................................
Patch Set 5:
(1 comment)
File src/osmo-hnbgw/context_map_rua.c:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/36788/comment/68a96698_8b64eb1d
PS5, Line 217: struct hnbgw_context_map *map = fi->priv;
> This is now an unused variable -- why did jenkins not complain about this? […]
looks like jenkins tested patchset 4, not the rebase in patchset 5 that was submitted
--
To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/36788?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: I3e1ad7a2aa71674a22a27c31512600f2de139032
Gerrit-Change-Number: 36788
Gerrit-PatchSet: 5
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-CC: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Wed, 22 May 2024 06:35:17 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: lynxis lazus.
fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/36861?usp=email )
Change subject: SMS-over-GSUP: set log context in gsm411_gsup_rx()
......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
> Why are you removing the log context lines?
Because I am moving setting the log context to the common code path.
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/36861?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: I3414953d2aa7b075fcee1cf6e5e76c527ae7b507
Gerrit-Change-Number: 36861
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-Attention: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-Comment-Date: Wed, 22 May 2024 03:43:23 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-MessageType: comment