* [ath9k-devel] Delayed Block Ack support ? @ 2014-02-28 10:26 Olivier Marce 2014-03-01 1:59 ` Adrian Chadd 0 siblings, 1 reply; 6+ messages in thread From: Olivier Marce @ 2014-02-28 10:26 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Delayed Block Ack support ? 2014-02-28 10:26 [ath9k-devel] Delayed Block Ack support ? Olivier Marce @ 2014-03-01 1:59 ` Adrian Chadd 2014-03-03 11:11 ` Olivier Marce 0 siblings, 1 reply; 6+ messages in thread From: Adrian Chadd @ 2014-03-01 1:59 UTC (permalink / raw) To: ath9k-devel 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> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Delayed Block Ack support ? 2014-03-01 1:59 ` Adrian Chadd @ 2014-03-03 11:11 ` Olivier Marce 2014-03-03 19:11 ` Adrian Chadd 0 siblings, 1 reply; 6+ messages in thread From: Olivier Marce @ 2014-03-03 11:11 UTC (permalink / raw) To: ath9k-devel 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> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Delayed Block Ack support ? 2014-03-03 11:11 ` Olivier Marce @ 2014-03-03 19:11 ` Adrian Chadd 2014-03-03 19:31 ` Olivier Marce 0 siblings, 1 reply; 6+ messages in thread From: Adrian Chadd @ 2014-03-03 19:11 UTC (permalink / raw) To: ath9k-devel Set the noack bit in the thx descriptor frame as well. Adrian On Mar 3, 2014 3:13 AM, "Olivier Marce" <Olivier.Marce@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> 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 -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140303/7b8a4faf/attachment.htm ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Delayed Block Ack support ? 2014-03-03 19:11 ` Adrian Chadd @ 2014-03-03 19:31 ` Olivier Marce 2014-03-03 19:48 ` Adrian Chadd 0 siblings, 1 reply; 6+ messages in thread From: Olivier Marce @ 2014-03-03 19:31 UTC (permalink / raw) To: ath9k-devel 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.Marce@alcatel-lucent.com > <mailto:Olivier.Marce@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.Marce@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 at 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Delayed Block Ack support ? 2014-03-03 19:31 ` Olivier Marce @ 2014-03-03 19:48 ` Adrian Chadd 0 siblings, 0 replies; 6+ messages in thread From: Adrian Chadd @ 2014-03-03 19:48 UTC (permalink / raw) To: ath9k-devel That's whta I've been told. -=a On 3 March 2014 11:31, Olivier Marce <Olivier.Marce@alcatel-lucent.com> wrote: > 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.Marce@alcatel-lucent.com >> <mailto:Olivier.Marce@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.Marce@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 at 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-03-03 19:48 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-28 10:26 [ath9k-devel] Delayed Block Ack support ? Olivier Marce 2014-03-01 1:59 ` Adrian Chadd 2014-03-03 11:11 ` Olivier Marce 2014-03-03 19:11 ` Adrian Chadd 2014-03-03 19:31 ` Olivier Marce 2014-03-03 19:48 ` Adrian Chadd
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.