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: <844f1a1dc72ec73df5a86864b410bbc490c4abdd.camel@gmail.com>
Subject: Re: [RFC 0/4] Allow live MAC address change
From:   James Prestwood <prestwoj@gmail.com>
To:     Kalle Valo <kvalo@codeaurora.org>
Cc:     Johannes Berg <johannes@sipsolutions.net>,
        linux-wireless@vger.kernel.org
Date:   Fri, 13 Sep 2019 09:17:37 -0700
In-Reply-To: <87a7b8lciz.fsf@tynnyri.adurom.net>
References: <20190904191155.28056-1-prestwoj@gmail.com>
         <d776271eac8b7cd24da6dbd21fb87186b30a0e7f.camel@sipsolutions.net>
         <4c43ea6a74cacc61184bc5b1387fecaa40711369.camel@gmail.com>
         <4909a428ee6fef2bf8b0e61841bc88062f534b13.camel@sipsolutions.net>
         <896183390a396e8e0508622eceb3664effcb3c30.camel@gmail.com>
         <87a7b8lciz.fsf@tynnyri.adurom.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

Hi Kalle,

On Fri, 2019-09-13 at 13:24 +0300, Kalle Valo wrote:
> James Prestwood <prestwoj@gmail.com> writes:
> 
> > I know 3ms doesn't seems like a lot but everything counts and from
> > my
> > testing this is even a further 20% improvement to doing so with
> > RTNL.
> > Plus the added simplicity to the userspace code/API. We have taken
> > a
> > lot of time to optimize IWD's connection times, and everything
> > counts.
> > The connection times are fast already, but when there is room for
> > improvement we will push for it, especially in situations like this
> > when the change is quite minimal and does not introduce much
> > complexity.
> 
> So what kind of _total_ connection times you get now?
> 

This really depends. Most of the optimizations I was referencing are
due to scanning optimizations and moving DHCP into IWD itself, but both
of these are kinda irrelevant in this case so I wont consider them.

With this change, looking at the time from CMD_CONNECT until EAPoL/key
setting has finished I calculated 111.4ms on average. This is about a
3.5x speed up from the current method (Power down + RTNL) which I
calculated to be 391.8ms average. Note, this is rough (averaged only 5
runs just now).

So the savings are still significant even if you look at the full
connection times. The difference between doing the MAC change with RTNL
vs CMD_CONNECT are not as drastic, but from my perspective I would say
what's the harm? Your gaining further speed ups with really no added
complexity.

Thanks,
James