On Wed, 2019-09-11 at 11:09 +0200, Johannes Berg wrote: > 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? I could have made this a bit more clear. I initially did measure the time to a full connection, including EAPoL, but the more I timed the more chance there was for scheduling delays that really threw off the results. Not that these results weren't valid, I just would have needed to time many many more runs to get a decent averaged time. The method of timings I took just isolated things a bit better. For the three methods below I measured the time from the connection initiation (either powering down via RTNL, changing MAC via RTNL, or sending CMD_CONNECT) until we got a success callback from CMD_CONNECT, including changing the MAC via RTNL in those cases. > > > 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. Yep exactly. > > > ================================== > > 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. Yeah, in IWD's case if this feature is supported we would be doing the MAC change on every connection (unless already changed previously) for privacy reasons. Out of curiosity how this behavior is different than the power down + RTNL MAC change (the current way of doing things)? If you power down the device, change the MAC, then power up does that MAC get reset after a disconnection/failure? > > 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. Sure, that would be great. That is definitely still a improvement to the existing way of doing things. Thanks, James > > johannes >
