This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.
Andreas Eversberg andreas at eversberg.euHolger Hans Peter Freyther wrote: > Good Morning, > > sched_poll is doing: > > llist_for_each_entry(tbf, &gprs_rlcmac_ul_tbfs, list) { > /* this trx, this ts */ > if (tbf->trx_no != trx || tbf->control_ts != ts) > continue; > /* polling for next uplink block */ > if (tbf->poll_state == GPRS_RLCMAC_POLL_SCHED > && tbf->poll_fn == poll_fn) > *poll_tbf = tbf; > if (tbf->ul_ack_state == GPRS_RLCMAC_UL_ACK_SEND_ACK) > *ul_ack_tbf = tbf; > if (tbf->dl_ass_state == GPRS_RLCMAC_DL_ASS_SEND_ASS) > *dl_ass_tbf = tbf; > if (tbf->ul_ass_state == GPRS_RLCMAC_UL_ASS_SEND_ASS) > *ul_ass_tbf = tbf; > } > llist_for_each_entry(tbf, &gprs_rlcmac_dl_tbfs, list) { > /* this trx, this ts */ > if (tbf->trx_no != trx || tbf->control_ts != ts) > continue; > /* polling for next uplink block */ > if (tbf->poll_state == GPRS_RLCMAC_POLL_SCHED > && tbf->poll_fn == poll_fn) > *poll_tbf = tbf; > if (tbf->dl_ass_state == GPRS_RLCMAC_DL_ASS_SEND_ASS) > *dl_ass_tbf = tbf; > if (tbf->ul_ass_state == GPRS_RLCMAC_UL_ASS_SEND_ASS) > *ul_ass_tbf = tbf; > } > > > New tbf's will be added to the front (llist_add). Is it on purpose > that the dl_tbfs are preferred over ul_tbfs and that the last of > each tbf's will be found? What is the reasoning for this? What will > collect/catch poll_fn's that are in the past? > > holger > > the function sched_poll() only refers to control messages and polling. for every frame number (fn) there is only one mobile that can be polled. polling is requested 13 frames earlier in a downlink RLC/MAC control block. because each downlink RLC/MAC control block addresses only one TBF, no more than one TBF will have the poll state set to GPRS_RLCMAC_POLL_SCHED for the current fn, and so there is no prio in the function above. generally: the uplink blocks that are polled have prio over normal uplink data blocks. (uplink traffic can wait, polled control messages not) the control messages (uplink ack, downlin/uplink assignment) have prio over normal downlink data blocks. (downlink traffic can wait, control messages not) assignment messges have prio over uplink ack messages. i did not implement any fairness for assignment control messages of each TBF, because the number of assignment control messages are always much lower than the number of data blocks, so there is no congestion, and i think there is no reason for any round-robin scheduling. if a poll_fn is in the past (time skew or no response), pcu_rx_time_ind() will discover that.