> 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
