adjust consumer and producer#12
Conversation
|
Can we rebase it to latest main so that the actual CI can get running? |
I have pulled from main, it shows everything up-to-date. |
|
I have linked this PR also to this branch for internal CI checking |
Aquaticfuller
left a comment
There was a problem hiding this comment.
Thanks for the kernel! With the latest commit, the kernel can now compile and run in RTL simulation.
Four clarifying questions inline, mostly about design intent. Happy to discuss further.
| #include "benchmark.h" | ||
|
|
||
| DlschInd dlsch_ind __attribute__((section(".data"))); | ||
| UeStateRpt ue_status_rpt_content __attribute__((section(".data"))); |
There was a problem hiding this comment.
Some structures, such as dlsch_ind and ue_status_rpt_content, are mainly used to model memory accesses. Since their loaded values are not really used later, the compiler may optimize these loads away. Should we mark them as volatile, or is there another preferred way to preserve this memory traffic?
| uint32_t total_cycle = CONSUMER_CORE_NUM * PDU_SIZE * CPU_FREQENCY / OUTPUT_DATARATE; | ||
| while (1) { | ||
| uint32_t start_timecycle = benchmark_get_cycle(); | ||
| TestDataStru dfx = {0}; |
There was a problem hiding this comment.
TestDataStru dfx is filled inside rlc_send_pkt(), but it is not read after the function returns. I would like to confirm whether this structure is only used to model per-packet temporary data movement, or whether it should be consumed by later logic.
| // pdcp_src_data[NUM_SRC_SLOTS-1][PDU_SIZE-1], | ||
| // benchmark_get_cycle()); | ||
| // DEBUG_PRINTF_LOCK_RELEASE(&printf_lock); | ||
| rlc_ctx.firstSduPktRxCycle = benchmark_get_cycle(); |
There was a problem hiding this comment.
What is the intended meaning of firstSduPktRxCycle? Currently, it is reset on every producer call, so it behaves more like a per-packet start timestamp rather than the first receive timestamp of the whole RLC flow. We should confirm whether this is intended.
| RcvPktHeader tmp = *(RcvPktHeader *)node->data; | ||
| /* write 64B to node mem */ | ||
| vector_memcpy32_m4_opt(((RcvPktHeader *)node->data + 1), &tmp, sizeof(RcvPktHeader)); | ||
| rlc_ctx.pdcpcount++; |
There was a problem hiding this comment.
Fields such as pktdelay, pdcpcount, and rlcOm[] may be written by multiple threads. This is fine for the current default test, but if we want to use more consumer cores, we may need to make these fields per-core, atomic, or protected by a lock.
No description provided.