maki/openairinterface5g
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Workaround for sched_response in PNF

Browse Source 
In monolithic, the sched_response mechanism ensures that FAPI messages
for one slot are not overwritten by scheduler instructions for the
following slots (i.e., it is like a memory allocation pool).

The allocation happens in nr_schedule_response(), not used by the PNF.
Hence, only deallocate when in monolithic.

The PNF uses a big ring buffer over all slots in a frame to ensure the
same.
This commit is contained in:
Robert Schmidt
2025-01-27 10:59:19 +01:00
parent 82f8c38d74
commit a32ada76c7
1 changed files with 8 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
executables/nr-gnb.c
+8 -3
View File
@@ -147,9 +147,14 @@ static void tx_func(processingData_L1tx_t *info)
ru_tx_func((void *)&syncMsgRU);
stop_meas(&info->gNB->phy_proc_tx);
}
/* this thread is done with the sched_info, decrease the reference counter */
LOG_D(NR_PHY, "Calling deref_sched_response for id %d (tx_func) in %d.%d\n", info->sched_response_id, frame_tx, slot_tx);
deref_sched_response(info->sched_response_id);
if (NFAPI_MODE == NFAPI_MONOLITHIC) {
/* this thread is done with the sched_info, decrease the reference counter.
* This only applies for monolithic; in the PNF, the memory is allocated in
* a ring buffer that should never be overwritten (one frame duration). */
LOG_D(NR_PHY, "Calling deref_sched_response for id %d (tx_func) in %d.%d\n", info->sched_response_id, frame_tx, slot_tx);
deref_sched_response(info->sched_response_id);
}
}
void *L1_rx_thread(void *arg)