Fairness of sched_poll

[Andreas Eversberg]

Holger 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.