Do you mean that setting noack bit is enough to make the HW not processing the BA ?
Regards On 03/03/2014 20:11, Adrian Chadd wrote: > 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 > <mailto: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.Marce@alcatel-lucent.__com > <mailto: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 > > <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 <mailto:ath9k-devel@lists.ath9k.org> > https://lists.ath9k.org/__mailman/listinfo/ath9k-devel > <https://lists.ath9k.org/mailman/listinfo/ath9k-devel> > > > > -- > Olivier Marcé > Alcatel-Lucent Bell Labs France > -- Olivier Marcé Alcatel-Lucent Bell Labs France _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
