From: James Prestwood <prestwoj@gmail.com>
To: Denis Kenzior <denkenz@gmail.com>, iwd@lists.linux.dev
Subject: Re: [PATCH v3 1/4] network: add network_update_known_frequencies
Date: Tue, 30 Jan 2024 04:30:42 -0800 [thread overview]
Message-ID: <6c91283d-7126-4233-9843-7ef6e0974ecb@gmail.com> (raw)
In-Reply-To: <6fc2ba34-e9fe-4d91-9709-1e9233903c4f@gmail.com>
Hi Denis,
On 1/29/24 6:54 PM, Denis Kenzior wrote:
> Hi James,
>
> On 1/26/24 14:22, James Prestwood wrote:
>> In order to support an ordered list of known frequencies the list
>> should be in order of last seen BSS frequencies with the highest
>> ranked ones first. To accomplish this without adding a lot of
>> complexity the frequencies can be pushed into the list as long as
>> they are pushed in reverse rank order (lowest rank first, highest
>> last). This ensures that very high ranked BSS's will always get
>> superseded by subsequent scans if not seen.
>>
>> This adds a new network API to update the known frequency list
>> based on the current newtork->bss_list. This assumes that station
>> always wipes the BSS list on scans and populates with only fresh
>
> Sort of. Strictly speaking it takes the frequencies scanned into
> account. So for example if we scan only certain 2.4GHz channels (say
> through DBus Scan API), then only BSSes within that frequency set will
> be updated. However, such scans are initiated one-after-the-other, so
> it is probably okay in this case.
Yeah we are technically re-adding the same frequencies for each
successive scan.
>
> One thing you might have to be careful of is limited scans due to
> roaming logic. But I think this series is good enough for now.
Yep this is why I didn't add anything in the roaming results just yet.
That and neighbor reports will require a bit more thought. I think for
roam scans/NR's we might be able to get away with doing the same thing,
but limited only to the connected network. In theory a roam scan should
still yield more updated frequencies than past scans, so we probably
could shove those to the head of the queue in the same fashion.
>
>> BSS entries. After the scan this API can be called and it will
>> reverse the list, then add each frequency.
>> ---
>> src/network.c | 40 ++++++++++++++++++++++++++++------------
>> src/network.h | 2 ++
>> 2 files changed, 30 insertions(+), 12 deletions(-)
>>
>> v4:
>> * Added an API to do the insertion once all the BSS's have been added
>> to the network object.
>> * I'm also ok adding something to ELL like:
>> l_queue_new_reverse(list);
>
> Given the sizes of our queues, it might be faster to reverse it twice
> than re-allocate / free one. Might even be a good candidate for
> l_newa() if you can keep a known bound on the number of entries.
>
>>
>> The current reverse is in-place, so I cant really use it unless I
>> wanted to reverse twice to get it back to decending order.
>>
>
> <snip>
>
>> bool network_bss_add(struct network *network, struct scan_bss *bss)
>> {
>> if (!l_queue_insert(network->bss_list, bss, scan_bss_rank_compare,
>> NULL))
>> return false;
>> - if (network->info)
>> - known_network_add_frequency(network->info, bss->frequency);
>> -
>> /* Done if BSS is not HS20 or we already have network_info set */
>> if (!bss->hs20_capable)
>> return true;
>
> This part looked like it belong with patch 2, so I moved it there.
>
> All patches applied, thanks.
>
> Regards,
> -Denis
>
prev parent reply other threads:[~2024-01-30 12:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 20:22 [PATCH v3 1/4] network: add network_update_known_frequencies James Prestwood
2024-01-26 20:22 ` [PATCH v3 2/4] station: use network_update_known_frequencies James Prestwood
2024-01-26 20:22 ` [PATCH v3 3/4] station: knownnetworks: limit quick scans to 5 freqs per network James Prestwood
2024-01-26 20:22 ` [PATCH v3 4/4] auto-t: add test for known frequency sorting/maximum James Prestwood
2024-01-30 2:54 ` [PATCH v3 1/4] network: add network_update_known_frequencies Denis Kenzior
2024-01-30 12:30 ` James Prestwood [this message]
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=6c91283d-7126-4233-9843-7ef6e0974ecb@gmail.com \
--to=prestwoj@gmail.com \
--cc=denkenz@gmail.com \
--cc=iwd@lists.linux.dev \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).