> Sorry I was wrong about the 8 bytes requirement. Although the > IPv6 protocol does try to maintain an 8-byte alignment the Linux > stack never does anything that requires that. > > So 4 bytes is enough.
Whew. Good to hear. > However, the wireless core is definitely not out of the woods. > It needs to support variable hardware header lengths that are > not always a multiple of 4. > > So here's my suggestion. Modify the wireless core to fix up any > packets which aren't aligned correctly. That should make it > work albeit in a way that's less than optimal. Not sure. On the one hand, yeah, that's something we should probably do, on the other hand this will suck because for most drivers either nothing needs to be done or the fixup is trivial. I suppose we should do this but stick in a WARN_ON_ONCE() or something, at least with mac80211 debug enabled. Also, we do plan to run these things on rather smallish embedded devices like APs that receive a lot of frames from many stations, and with 11n we're pushing speeds up by quite a bit. I'm wary of putting more code into the generic receive path. > Then for each driver where you care about this performance > (seriously I wouldn't for the speeds these things run at :), > pick the most common wireless hardware header length and have > the IP (or any other upper-level protocol) header aligned to > at least 4 bytes. Or better if you know what hardware header > length that you're going to get (e.g., based on what mode you're > in) then do the skb_reserve accordingly. Well, you can receive non-QoS frames even in QoS or WPS frames in any other mode etc. so you can't really make any promises as which will be more common. Bu in practice all (sane) hardware makes sure things are aligned properly. > It's a good thing these things aren't running at 10Gb :) For sure! johannes
signature.asc
Description: This is a digitally signed message part
