[ath9k-devel] Delayed Block Ack support ?

[ath9k-devel] Delayed Block Ack support ?

[Olivier Marce]

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] Delayed Block Ack support ?

[Adrian Chadd]

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

[ath9k-devel] Delayed Block Ack support ?

[Olivier Marce]

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 

[ath9k-devel] Delayed Block Ack support ?

[Adrian Chadd]

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 

[ath9k-devel] Delayed Block Ack support ?

[Olivier Marce]

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

[ath9k-devel] Delayed Block Ack support ?

[Adrian Chadd]

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