neels has submitted this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/31427 )

Change subject: various comment tweaks ......................................................................

various comment tweaks

Change-Id: Ie40aa672948062282c566c90300f6e96963e05ec --- M include/osmocom/hnbgw/context_map.h M src/osmo-hnbgw/context_map.c M src/osmo-hnbgw/mgw_fsm.c M src/osmo-hnbgw/ps_rab_ass_fsm.c 4 files changed, 26 insertions(+), 11 deletions(-)

Approvals: Jenkins Builder: Verified laforge: Looks good to me, approved pespin: Looks good to me, approved

diff --git a/include/osmocom/hnbgw/context_map.h b/include/osmocom/hnbgw/context_map.h index 1342da5..3a145b6 100644 --- a/include/osmocom/hnbgw/context_map.h +++ b/include/osmocom/hnbgw/context_map.h @@ -47,17 +47,22 @@

enum hnbgw_context_map_state state;

- /* FSM instance for the MGW */ + /* FSM instance for the MGW, handles the async MGCP communication necessary to intercept CS RAB Assignment and + * redirect the RTP via the MGW. */ struct osmo_fsm_inst *mgw_fi;

- /* FSMs handling RANAP RAB assignments for PS. list of struct ps_rab_ass. For PS RAB Assignment, each Request - * and gets one ps_rab_ass FSM and each Response gets one ps_rab_ass FSM. The reason is that theoretically, each - * such message can contain any number and any combination of RAB IDs, and Request and Response don't - * necessarily match the RAB IDs contained. In practice I only ever see a single RAB matching in Request and - * Response, but we cannot rely on that to always be true. The state of each RAB's PFCP negotiation is kept - * separately in the list hnbgw_context_map.ps_rabs, and as soon as all RABs appearing in a PS RAB Assignment - * message have completed their PFCP setup, we can replace the GTP info for the RAB IDs and forward the RAB - * Assignment Request to HNB / the RAB Assignment Response to CN. */ + /* FSMs handling RANAP RAB assignments for PS, list of struct ps_rab_ass. They handle the async PFCP + * communication necessary to intercept PS RAB Assignment and redirect the GTP via the UPF. + * + * For PS RAB Assignment, each Request gets one ps_rab_ass FSM and each Response gets one ps_rab_ass FSM. + * The reason is that theoretically, each such message can contain any number and any combination of RAB IDs, + * and Request and Response don't necessarily match the RAB IDs contained. In practice I only ever see a single + * RAB matching in Request and Response, but we cannot rely on that to always be true. + * + * The state of each RAB's PFCP negotiation is kept separately in the list ps_rabs, and as soon as all RABs + * appearing in a PS RAB Assignment message have completed their PFCP setup, we can replace the GTP info for the + * RAB IDs and forward the RAB Assignment Request to HNB / the RAB Assignment Response to CN. + */ struct llist_head ps_rab_ass;

/* All PS RABs and their GTP tunnel mappings. list of struct ps_rab. Each ps_rab FSM handles the PFCP diff --git a/src/osmo-hnbgw/context_map.c b/src/osmo-hnbgw/context_map.c index 39b9b50..96365fb 100644 --- a/src/osmo-hnbgw/context_map.c +++ b/src/osmo-hnbgw/context_map.c @@ -111,7 +111,7 @@ LOGHNB(hnb, DMAIN, LOGL_INFO, "Creating new Mapping RUA CTX %p/%u <-> SCU Conn ID %p/%u\n", hnb, rua_ctx_id, cn_if_new, new_scu_conn_id);

- /* alloate a new map entry */ + /* allocate a new map entry. */ map = talloc_zero(hnb, struct hnbgw_context_map); map->state = MAP_S_NULL; map->cn_link = cn_if_new; diff --git a/src/osmo-hnbgw/mgw_fsm.c b/src/osmo-hnbgw/mgw_fsm.c index 764e9a7..fe1e227 100644 --- a/src/osmo-hnbgw/mgw_fsm.c +++ b/src/osmo-hnbgw/mgw_fsm.c @@ -780,7 +780,7 @@ }

/*! Release the FSM and clear its associated RTP streams. - * \ptmap[in] map hanbgw context map that is responsible for this call. + * \ptmap[in] map hnbgw context map that is responsible for this call. * \returns 0 on success; negative on error. */ int mgw_fsm_release(struct hnbgw_context_map *map) { diff --git a/src/osmo-hnbgw/ps_rab_ass_fsm.c b/src/osmo-hnbgw/ps_rab_ass_fsm.c index e676c2c..e232de8 100644 --- a/src/osmo-hnbgw/ps_rab_ass_fsm.c +++ b/src/osmo-hnbgw/ps_rab_ass_fsm.c @@ -620,6 +620,7 @@ rab->resp_fi = NULL; }

+ /* remove from map->ps_rab_ass */ llist_del(&rab_ass->entry); }