RE: Regarding A-MPDU status field

Hi,

>Having a driver that supports this field would also be required so we can judge its implementation,
>and so far I haven't had a chance to add support to any driver. If you can do that for any of the QCA
>drivers that would be helpful.
Once we settle upon the additional content (discussed below), I'll see if I can get someone to try this out on ath9k. Else, I would love to add the support myself during one of the coming weekends when I get spare time.

>Also, the question about the contents came up at some points 
I agree it would be a good idea to discuss additional contents before finalizing the field. I'll present some suggestions to restart the discussion. Requesting feedback from the group.

> -- it might also be helpful to know the padding length before/after (?) the packet for example.
We can add
1) Padding length information
a) value of padding length after the MPDU, and
b) (debatable) total padding length before the subframe for the special case of preceding delimiters with MPDU length zero used to meet minimum MPDU start spacing requirements. All the octets of the preceding 'zero delimiters' together form the pad, as I understand. Note that this information might not be provided by some hardware.
If an MPDU (not 'zero delimiter') is actually present prior to the current subframe for which radiotap info is being displayed, 1b) should be zero for the current subframe. Post MPDU pad length information for the prior MPDU would anyway be available (assuming the containing subframe of the prior MPDU is not corrupted).

Additionally:
2) A bit to indicate if this is the last subframe in the A-MPDU. Though there might be other ways to infer this information, having it as an explicit field would provide convenience. 
3) A bit to indicate if the Delimiter CRC is in error.
4) (Debatable) Delimiter CRC value itself. I don't know if there is any hardware which returns the actual value to software. Anyway, having it as part of the field will allow platforms which do possess the capability, to provide this information. It may come in handy for some users.

For all the above fields, there should be corresponding bits to indicate if the value is valid.

Regds,
Krishna Rao

-----Original Message-----
From: Johannes Berg [mailto:[email protected]] 
Sent: Wednesday, November 02, 2011 2:12 PM
To: Rao, Krishna
Cc: [email protected]
Subject: Re: Regarding A-MPDU status field

[please try writing text-only email]

> I noticed that the A-MPDU status field has been listed under 
> ‘Suggested Fields’ (http://www.radiotap.org/suggested-fields). I feel 
> having this field will make things easier in some scenarios, 
> especially when carrying out performance related analysis.

Indeed.

> I would like to request for this field to be made official. 

I had worked on this for a while, but never followed through on the process of formally adopting it.

Having a driver that supports this field would also be required so we can judge its implementation, and so far I haven't had a chance to add support to any driver. If you can do that for any of the QCA drivers that would be helpful.

Also, the question about the contents came up at some points -- it might also be helpful to know the padding length before/after (?) the packet for example.

johannes