Set the noack bit in the thx descriptor frame as well. Adrian On Mar 3, 2014 3:13 AM, "Olivier Marce" <olivier.ma...@alcatel-lucent.com> wrote:
> 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 >> <olivier.ma...@alcatel-lucent.com> 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@lists.ath9k.org >>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>> >> >> > -- > Olivier Marcé > Alcatel-Lucent Bell Labs France >
_______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
