From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier Marce Date: Mon, 3 Mar 2014 12:11:28 +0100 Subject: [ath9k-devel] Delayed Block Ack support ? In-Reply-To: References: <5310644A.10707@alcatel-lucent.com> Message-ID: <53146360.8010608@alcatel-lucent.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org Hi, many thanks for these hints. When looking at the details needed to implement Delayed BA, I have concerns with the HW behavior. In the best of my understanding, HW manages the sent/received ACK as well as the frame retransmission. Then I wonder how the transmitter HW will behave when it will get a Delayed BA. Attached are some flow charts that depict my understanding of normal behavior (slide 1) and how a SW Delayed BA could behave (slide 2) In slide 2 I assume that : - Retry=0 at transmitted side - No Ack set at received side - Delayed BA is not handled by HW at transmitted side, but I don't know how to make it possible. Best regards On 01/03/2014 02:59, Adrian Chadd wrote: > hi, > > Well, the point is that the receiver will know what was successfully > transmitted as it's tracking the sequence number space of the received > packets. > > So, you need > > * some way on the receiver to construct a bitmap from that to > determine what the current block-ack response should look like; > * add in the code to handle a block-ack request and respond with the > current block-ack window (in a manual BA, right? I forget.) > * announce you can do delayed-blockack; > > Then on the transmitter: > > * add in logic to transmit frames with no-ACK set; > * then add some way to know when to send the BA request - eg, once the > hardware has reported it's finished sending the frame (it won't have > an ACK, but it'll at least tell you that it's actually DMAed it out > and sent it out the air) > * .. then send the BA request > * And then add code to handle the BA response and update the transmit > side BA tracking (that's done right now by looking inside the TX > completion descriptor.) > > > > -a > > > On 28 February 2014 02:26, Olivier Marce > wrote: >> Hi, >> I'm looking for Delayed Block Ack support in ath9k. >> >> Is the situation different than on Nov 2012 ? >> https://lists.ath9k.org/pipermail/ath9k-devel/2012-November/009867.html >> >> I wonder how what have been suggested could work: >>> >>> * send aggregate frames, up to whatever your window size is; >>> * wait a little bit; >> waiting from when ? Once the frames passed to the HW to be transmitted ? >> But will not the HW transmit Immediate BA ? If disabled, how to get a >> status of received/not received frames ? >> >> > * send a BA; >> BAR I guess >> >> > * respond with a manually constructed BA frame with the current >>> state of the BA window. >> >> See before : how to get the state of the BA window if the HW did not >> complete the transmission. >> >> Thanks >> >> -- >> Olivier Marc? >> Alcatel-Lucent Bell Labs France >> _______________________________________________ >> ath9k-devel mailing list >> ath9k-devel at lists.ath9k.org >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel > -- Olivier Marc? Alcatel-Lucent Bell Labs France -------------- next part -------------- A non-text attachment was scrubbed... Name: DelayedBAFlowChart.pdf Type: application/pdf Size: 29880 bytes Desc: not available Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140303/36d8fd81/attachment-0001.pdf