Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <4c43ea6a74cacc61184bc5b1387fecaa40711369.camel@gmail.com>
Subject: Re: [RFC 0/4] Allow live MAC address change
From:   James Prestwood <prestwoj@gmail.com>
To:     Johannes Berg <johannes@sipsolutions.net>,
        linux-wireless@vger.kernel.org
Date:   Wed, 11 Sep 2019 08:54:19 -0700
In-Reply-To: <d776271eac8b7cd24da6dbd21fb87186b30a0e7f.camel@sipsolutions.net>
References: <20190904191155.28056-1-prestwoj@gmail.com>
         (sfid-20190904_221357_305070_478BF6CA) <d776271eac8b7cd24da6dbd21fb87186b30a0e7f.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

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
>