[rt2x00-users] Alignment, padding and IV/ICV
benoit.papillault at free.fr
Tue Dec 1 21:09:04 UTC 2009
Ivo van Doorn a écrit :
>> Part 1:
>> 1. mac80211 sends us a packet in rt2x00mac_tx
>> 2. we remove IV/ICV from the packet if applicable (we copy IV to
>> 3. we call rt2x00queue_insert_l2pad which is doing 3 things : align
>> 802.11 header, align 802.11 payload, add padding. That might be a bit
>> too much.
> Partially right, there is a if-statement if it should apply l2-padding or not,
> when l2 padding is required, it is cheaper to align the data as well since
> we are moving the header and/or payload anyway.
OK. I understand this is an implementation optimization, but
functionally, it should be the same isn't it?
>> 4. we call rt2x00usb_write_tx_data add TXINFO / TXWI in front of the skb
>> 5. Finally, we submit the skb to HW in rt2x00usb_kick_tx_entry via
>> Part 2: basically, we need to revert what was done in Part 1 since
>> that's what mac80211 needs (at the point we call ieee80211_tx_status).
>> 1. It starts in rt2x00usb_interrupt_txdone, calling rt2x00lib_txdone
>> 2. We remove L2 padding with rt2x00queue_remove_l2pad
>> 3. We add IV again in the skb with rt2x00crypto_tx_insert_iv (and what
>> about ICV?)
> The hardware generates the ICV, so mac80211 didn't provide the ICV to
> the driver. So we don't need to give it back to mac80211, neither can we
> because we don't know what the device did for ICV.
Thanks for clarifying.
>> RX path analysis (this does not fully represent is doing exactly, but
>> it's only for understanding) :
>> 1. we receive a packet from HW in rt2x00usb_interrupt_rxdone
>> 2. we remove header (RXINFO+RXWI) & footer (RXD+USB pad) in
>> 3. we remove L2 pad between 802.11 header and 802.11 payload if applicable
>> 4. we set skb->len to rxdesc.size to remove padding at the end of the frame
>> 5. we reinsert IV between header/payload and ICV at the end (after
>> payload) if applicable
>> 6. we align payload : it seems that mac80211 already takes care of that
> As far as I know mac80211 will WARN_ON() when the payload is aligned,
> but will not perform the alignment itself. That is why rt2x00lib is doing it.
I talked to Johannes, alignment is done in ieee80211_rx() when it calls
ieee80211_deliver_skb() [inside ieee80211_rx_h_data].
>> If so: we can get rid of alignment on RX, it's up to mac80211 to handle
>> it. On TX, we should only care about header alignment (after L2 padding
>> is done, which in most case but not all, will also align payload). What
>> are the real HW constraint on alignment on TX? Is it
>> architecture/chipset/DMA engine dependant?
> I know that beacons _must_ be aligned, but for the other frame types
> I wouldn't know.
OK. My feeling is that if we try to achieve header alignment + payload
alignment + L2 pad at the same time, it will not work. For instance,
with an ACK frame (header_length=10, l2pad=0), we cannot align both
header + payload.
If we align header for all frames + payload for data frame only, we then
- control frame : hdrlen = 16 so if we align header, payload will be
align, except for ACK/CTS (hdrlen=10), which we don't care.
- invalid frame : we don't care, no padding
- data frame : if we align header+payload, L2pad will be OK as well
(since hdrlen+l2pad is always a multiple of 4).
- management frame : hdrlen=24, already multiple of 4. So alignment of
header will also align the payload.
>> What about splitting the functions in 3 groups :
>> - header alignment
>> - L2 padding
> Last time I wrote this code, header alignment is done automatically when L2 padding
> is added. So we don't need to split that, there is a seperate header alignment function
> in case no L2 padding is required.
>> - crypto IV/ICV ?
> Nothing needs to be changed here I think.
More information about the users