15 May
2024
15 May
'24
3:58 a.m.
I believe we have seen cases
at other customerswhere the hNB comes back with a different identity every time it
connects,
so one would be leaking counters if they were persistent, as in reality every reconnect a
new
one would be allocated and all old ones would be stale.
oh, i didn't expect that.
Cleaning up on disconnect seems necessary then.
I did not consider this for the reason that osmo-hnbgw creates struct
hnb_persistent for each cell id it sees connecting, and adds rate_ctrs for
each. This was implemented only recently, so I adopted that premise.
This means we already have such a "leak" situation, rate_ctrs being added and
never removed. I think I'd add a configurable idle timeout for hnb_persistent?
It does make sense to me to let the nft named counters exist for the same time
that the struct hnb_persistent's cell id and rate_ctrs exist. So I would delete
the named counters upon hnb_persistent_free().
There is a hnb_persistent_free() function, but it is so far only invoked from
vty command 'no hnb IDENTITY_INFO' -- I'd add that idle timeout. We so far
don't rate_ctr_group_free(ctrs) in hnb_persistent_free() -- I'd add it now.
Do you agree with these ideas?
~N