[rt2x00-users] Padding and alignment for rt2800pci / rt2800usb
Ivo van Doorn
ivdoorn at gmail.com
Fri Aug 28 19:34:19 UTC 2009
> 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
> 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.
More information about the users