From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier Marce Date: Mon, 3 Mar 2014 20:31:09 +0100 Subject: [ath9k-devel] Delayed Block Ack support ? In-Reply-To: References: <5310644A.10707@alcatel-lucent.com> <53146360.8010608@alcatel-lucent.com> Message-ID: <5314D87D.6080309@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 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" > > 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 > > 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 > -- Olivier Marc? Alcatel-Lucent Bell Labs France