[rt2x00-users] Padding and alignment for rt2800pci / rt2800usb

[Ivo van Doorn]

Hi,

> TX path of rt2800pci :
> 
> The hardware has no alignment requirement. It has been tested by moving
> the TX buffer content by 1 byte. In fact, in the original code that I've
> been using so far, I noticed that the skb->data and skbdesc->skb_dma
> always ended by 0x4f!
> 
> Padding between 802.11 header and 802.11 data is required for some data
> frames. I don't know if a padding is required at the end of the frame to
> have the whole frame be a multiple of 4.

Looking at the previous chipsets the frame itself doesn't need to be a multiple
of 4. That is only a requirement for USB hardware.

> RX path of rt2800pci :
> 
> The allocated skb is already aligned so there is not much problem for
> the hardware. Padding between 802.11 header and 802.11 data needs to be
> removed before sending the frame to mac80211. However, the L2PAD flag is
> set by the hardware even if the frame size is too small, so some
> checking is needed. mac80211 checks for alignment : the 802.11 header
> must be aligned to a multiple of 2 and the 802.11 data needs to be
> aligned on a multiple of 4. In fact, there are 2 cases :
> 
> L2 padding is 0 byte (or no padding): both 802.11 header and 802.11 data
> will be aligned to a 4 bytes boundary. So we are fine with mac80211.
> 
> L2 padding is 2 bytes : once the L2 padding has been removed, we have
> 802.11 header aligned to a 2 bytes boundary and 802.11 data still
> aligned on 4 bytes boundary. So, once again, we are fine with mac80211.
> 
> During my experiment, I found out that the hardware (by checking SDL0
> and SDL1) adds a padding at the end of the 802.11 data part to have a
> total that is multiple of 4 bytes.

So only thing that needs fixing here is always let rt2x00lib check for
L2 padding rather then depending on the txdesc flag?

> TX path of rt2800usb :
> 
> This is pretty much the same as rt2800pci. However, there are some added
> padding between the 802.11 data and the end of the frame to be on a 4
> bytes boundary. Then 4 bytes are added and for some frame size (based on
> the USB endpoint max packet size), again 4 bytes are added again!

Yup, that is traditional USB magic. Happens in all Ralink USB drivers, and I
assume in USB drivers from other vendors as well.

> RX path of rt2800usb :
> 
> This is pretty much the same as rt2800pci. However, the RX frame format
> is very different. It is : RXINFO|RXWI|802.11 header|L2PAD|802.11
> data|pad|RXD|USB pad|
> 
> The L2PAD flag is located in the RXD which is at the end of frame.
> USB pad is 0 or 4 bytes based on ... I don't know :-).
> RXD is aligned to a 4 bytes boundary.
> (RXWI + 802.11 header + L2PAD + 802.11 data + pad) size is stored in RXINFO.
> 
> Based on those information, it's pretty straightforward to access RXD
> and get L2PAD flag. For alignment, the same stuff as rt2800pci applies,
> so once again, we are fine with mac80211.
> 
> *** Latest information *** : The RX buffer can contains multiple 802.11
> frames!!! (which is why lots of frames were lost...). I have not fully
> understood how to decode this and how to send those "sub" frames to
> mac80211. It might needs some work in rt2x00lib...

But you do have a method on detecting that there are multiple frames?
Or did you founds that out by dumping the frames to userspace and
analysing them?

> Regards,
> Benoit
> PS: I don't always received message sent to the list, when apparently,
> the list is in CC.

Well the list had some problems the last couple of days, so perhaps this is
fixed now? Let me know when it hasn't.

Ivo