please ignore current series, i am sending the whole series over, this series were sent by mistake thanks Ron On 1/10/08, Ron Rindjunsky <ron.rindjunsky@xxxxxxxxx> wrote: > Hi folks > > This series is published as RFC, as I would like to address the design > for A-MPDU TX, reflected in the API and in implementation, since the > initiator side (Tx) is a bit more complicated then the recipient side (Rx). > > Recipient (Rx) flow: > ==================== > regular Rx -> addBA request arrives -> addBA response send -> Rx switches to > A-MPDU from starting sequence number published in addBA request -> A-MPDU Rx > -> delBA arrives. > > What we would expect from Initiator (Tx) flow: > ================================================ > regular Tx -> addBA request send -> addBA response arrives -> Tx switches to > A-MPDU from starting sequence number published in addBA request -> A-MPDU Tx > -> delBA send > > What are the pitfalls in Tx flow: > ================================= > 1 - Session "handshake" idle time - As addBA request/response is being done > during regular data flow the initiator can not just stop Tx and wait for > recipient answer because it will cause a serious drop in performance, > especially considering the fact that recipient can decline the request, > so during this period Tx should continue, much the same like recipient > does not stops Rx after addBA request arrives... > > 2 - Starting sequence number (ssn) - Because we don't want to stop Tx flow, > starting sequence number for first possible A-MPDU frame should be forecasted, > either based on mac80211 book keeping, but more likely on low-level driver > estimation upon current HW queues status that are likely buffered with frames > for Tx in regular mode, and in that case this forecast should be supplied to > mac80211 by low level driver so a correct addBA request with the ssn will be > issued to recipient. > > 3 - Finish Tx of regular MPDUs - If recipient does accept the addBA, and > A-MPDU session should start, low level driver should first check that all > queued frames for regular Tx on same TID prior to published ssn were delivered > to recipient, and only then allow A-MPDU Tx. When stopping A-MPDU the opposite > should happen, finish sending all A-MPDU, and only then send delBA and > do regular Tx. > > 4 - Queue policy - regular Tx is based on QoS AC granularity, while A-MPDU Tx > is based on TID/Receiving Address granularity, so already upon A-MPDU > _intention_ (before addBA request is issued), already a classification change > should occur, and return to QoS granularity only if aggregation stopped or > declined. > > 5 - Queues drain (HW queues and Qdiscs) - so, derived from the above, > either when starting or stopping A-MPDU session, HW queues and Qdiscs should > first be examined and drained, so no packet loss due to wrong Tx mode, > delay in Tx, or leftovers that were buffered in the queues will occur. > > So, considering these constraints, low-level driver needs to handle next issues: > 1 - Starting sequence number (deliver to mac80211). > Done through the ampdu_action ops interface. > 2 - Make sure HW queue are clear to Tx (TID criteria) and ready to > A-MPDU when starting aggregation (and report to mac80211 MLME), > and clear and ready to regular Tx when stopping aggregation > (and report to mac80211 MLME), This readiness will be reported > to mac80211 through the supplied call backs. > > While mac80211 will have to control: > 1 - Session level (MLME), you can review these changes inside the patches. > 2 - AC/TIDxRA queue policy (Qdisc). I have a functioning solution here, > but will be glad to hear comments and suggestions, as I not sure about > this implementation. > > Thanks everyone > Ron > > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > - > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
