linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: James Prestwood <prestwoj@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org
Subject: Re: [RFC 0/4] Allow live MAC address change
Date: Tue, 17 Sep 2019 10:46:52 +0300	[thread overview]
Message-ID: <87imprbc0j.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <844f1a1dc72ec73df5a86864b410bbc490c4abdd.camel@gmail.com> (James Prestwood's message of "Fri, 13 Sep 2019 09:17:37 -0700")

James Prestwood <prestwoj@gmail.com> writes:

> 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.

For user experience scanning and DHCP are also important, what kind of
numbers you get when those are included? No need to have anything
precise, I would like just to get an understanding where we are
nowadays.

> 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).

Ok, thanks.

> 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.

As you only provided one number it's clear that you are only working
with one driver. But for us it's not that simple, we have to support a
myriad of different types of hardware and there can be complications and
additions later on, even for simple features. Like the dynamic power
save support I submitted to mac80211 over 10 years which was supposed to
be simple, and still we talk almost every year how do we get it out of
mac80211 as it makes maintenance difficult.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  reply	other threads:[~2019-09-17  7:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-04 19:11 [RFC 0/4] Allow live MAC address change James Prestwood
2019-09-04 19:11 ` [RFC 1/4] nl80211: Add LIVE_ADDR_CHANGE feature James Prestwood
2019-09-04 19:11 ` [RFC 2/4] {nl|cfg}80211: Support mac change as part of SME Connect James Prestwood
2019-09-04 19:11 ` [RFC 3/4] mac80211: Support LIVE_ADDRESS_CHANGE feature James Prestwood
2019-09-04 19:11 ` [RFC 4/4] {nl,cfg}nl80211: Support mac change for mlme_authenticate James Prestwood
2019-09-11  9:09 ` [RFC 0/4] Allow live MAC address change Johannes Berg
2019-09-11 15:54   ` James Prestwood
2019-09-11 18:25     ` Johannes Berg
2019-09-11 19:20       ` James Prestwood
2019-09-13 10:24         ` Kalle Valo
2019-09-13 16:17           ` James Prestwood
2019-09-17  7:46             ` Kalle Valo [this message]
2019-09-17 15:40               ` Denis Kenzior
2019-09-17 18:44                 ` Bob Marcan
2019-09-17 18:47                   ` Ben Greear
2019-09-17 19:05                   ` Marcel Holtmann
2019-09-17 19:11                   ` Steve deRosier
2019-09-17 16:11               ` James Prestwood
2019-09-13 18:49         ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87imprbc0j.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@codeaurora.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=prestwoj@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).