Hi James, TBH, I'm still not really convinced. > I have taken some timings for all 3 ways of changing the MAC. Powered > change via RTNL, non powered via RTNL, and changing through > CMD_CONNECT. All times were taken in microseconds and tested on an > Intel 7260 PCI wireless adapter: >From where to where did you measure? I mean, clearly you cannot have counted all the way to the connection? > Powered via RTNL: > > Average: 294508.9 > Min: 284523 > Max: 300345 > > ================================== > Non-Powered via RTNL: > > Average: 14824.7 > Min: 11037 > Max: 17812 > > Speedup from powered change: 19.87x (average) I'm assuming that this version is the IFF_LIVE_ADDR_CHANGE + setting the MAC address via RTNL? If so, yeah, obviously not powering off the firmware will be much faster than powering it off. That's an easy win really. > ================================== > via CMD_CONNECT: > > Average: 11848.7 > Min: 9748 > Max: 17152 > > Speedup from powered change: 24.86x (average) And this really only gives you a gain of 3ms. That'd be nice, but like I said before, it's not the only thing we/you should be thinking about. One fundamental issue I have with this is that you're now combining together temporary with persistent state changes. After a disconnection (or connection failure), the interface usually goes back to its previous state. With this change, you're keeping the MAC address modified though. Sure, you don't care (because you're probably going use a new random address later anyway), but these are still things we should consider in an API. I'll happily take the subset of the patches that implements the IFF_LIVE_ADDR_CHANGE in mac80211, but I don't think the 3ms win there wins over having a well-defined API. johannes
