Re: Re: adding ba_policy member in drv_ampdu_action op - request information

[vivekanandah@posedge.com]

hi johannes,

sorry for the delayed response. i was off from work for a few days.

is'nt the station's capability and the AP capability intersected during 
association? i always thought that the comment was mis-represented.

i did a small test and i see that the stations capability is actually 
the subset of AP capabilities that both support.
if that is the case, then we do not have to check for the capability 
independently there! do i miss something in my understanding?

also, if what i have stated above is correct, then yes, i feel delayed 
block ack as a feature might need to be implemented on mac80211 and then 
check for the same.

thanks and regards
Vivek


On Thu, 13 Dec 2012 15:01:59 +0100, Johannes Berg wrote:
> Hi Vivek,
>
>> if you are referring to the addba-request to transmit a ADDBA with
>> delayed block ack, yes, i accept what you have stated. but, then we
>> would need to support delayed block ack on the TX.
>>
>> for my query, i was thinking more with respect to the receive side 
>> of
>> an AP.
>
> Ah, ok.
>
>> if, let us say a particular station is capable of delayed block ack
>> which might not be a linux station(presently it seems, linux box 
>> will
>> only pursue immediate block ack), then on receive of a block ack
>> request, the lower layer can just send an ack if the policy is known 
>> to
>> be delayed block ack.
>
> Right now, a mac80211-based station should probably never even 
> advertise
> that it is delayed-BA capable since it won't correctly be handled.
> Therefore, any other station must not ask for a delayed-BA session in
> its AddBA request. And in fact, ieee80211_process_addba_request() 
> drops
> frames that ask for delayed BA.
>
> So I guess what you're really saying is that you want to implement
> delayed BA and address the todo item in
> ieee80211_process_addba_request() that says:
>
>         /* XXX: check own ht delayed BA capability?? */
>
> i.e. add a check here for our own capability and add a new parameter 
> to
> let the driver know...
>
> Overall that seems reasonable.
>
> johannes