Hi, > For the TX path, I don't think a memmove() of the header further down is > really expensive, it should be within the CPU cache since we operate on > the skb header a lot. However, you'd have to undo that too before TX > status reporting to get radiotap working properly :/ > > > I agree, but overall I think this would mean for rt2x00 it will be easier to stop > > sending the skb->data directly to the USB host and use the preallocated DMA > > instead. > > Especially the RX path could benefit since otherwise it will be continuously using > > memmove on the header and payload to insert the IV and have the payload 4-byte aligned. > > How would you go about handling out-of-band IV in the RX path? In the TX > path, I can see how you could do that, but in RX? I'm not sure if I understand completely what you mean but rt61pci/rt73usb hardware does the following: 1) Receive frame 2) Determine key from register 3) Put IV/EIV into descriptor 4) Decrypt 5) Notifies driver about the frame + decryption status So the IV/EIV is only provided for information about the description. It will require some testing to see what happened to the IV/EIV when decryption failed... Side-information: rt2500pci and rt2500usb handle this differently because they require the driver to set the key before a frame can be decrypted. > In any case, if you can make usable patches for out-of-band IV I'm not > totally against it, but I'd like to keep the overhead as low as > possible. In particular, I was thinking of embedding tx_conf into > skb->cb[] so you wouldn't have space in there for the IV. Well as an alternative to adding it to tx_control, perhaps a callback function for drivers could be provided? At the moment mac80211 calls: ieee80211_tkip_add_iv(pos, key, (u8) (key->u.tkip.iv16 >> 8), (u8) (((key->u.tkip.iv16 >> 8) | 0x20) & 0x7f), (u8) key->u.tkip.iv16); to insert the IV into the skb, if the driver could get a calback function that calls the above function and writes the result into a char* buffer you get the same effect except that the driver can put the iv wherever it wants. That way rt2x00 doesn't have to set the IEEE80211_KEY_FLAG_GENERATE_IV flag, and can request the IV manually from mac80211. Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
