From: Ben Greear <greearb@candelatech.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [WT PATCH 4/6] mac80211: Add per-sdata station hash, and sdata hash.
Date: Fri, 26 Jul 2013 08:27:28 -0700 [thread overview]
Message-ID: <51F29560.3080605@candelatech.com> (raw)
In-Reply-To: <1374828780.8248.24.camel@jlt4.sipsolutions.net>
On 07/26/2013 01:53 AM, Johannes Berg wrote:
> On Thu, 2013-07-11 at 08:29 -0700, Ben Greear wrote:
>
>>> I also don't like maintaining two separate hash tables and all that.
>>>
>>> I'd reconsider if you actually remove the hash entirely, but that'll be
>>> tricky to walk the station list and will quite possibly make the RX path
>>> there more expensive?
>>
>> Remove local->sta_hash ?
>
> To be honest, I'm undecided. Yes, I was thinking that, but I also think
> having a huge hashtable like that for each virtual interface is way
> overkill, in particular for station interfaces that usually have one
> peer (the AP) and maybe a few TDLS peers. Or P2P-Device interfaces that
> have no peers at all ...
>
> I don't see a good way to improve the hash either, since we don't always
> (e.g. in RX path) have the interface address.
>
> The basic problem really is that the hash now is designed to work well
> for more regular use cases than yours, where you talk to any number of
> different stations but degrades really badly when you talk only to a
> single one many times. That use case is really special, and I don't want
> to 'fix' that in a way that would make the other use case significantly
> worse in memory consumption or CPU utilisation.
I could make the hash size configurable I suppose, or just make it always
be small for stations and larger for AP interfaces. That should
mitigate the memory usage issues. The sdata hash in the wiphy can
remain big, but there are rarely more than a few wiphy in a system, so
I think the cost is low for that.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2013-07-26 15:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-29 22:58 [WT PATCH 1/6] mac80211: Add debugfs file to show station-hash counts greearb
2013-06-29 22:58 ` [WT PATCH 2/6] mac80211: Make un-found-rate splat a warn-once greearb
2013-07-11 8:52 ` Johannes Berg
2013-06-29 22:58 ` [WT PATCH 3/6] wireless: Add memory usage debugging greearb
2013-07-11 8:53 ` Johannes Berg
2013-06-29 22:58 ` [WT PATCH 4/6] mac80211: Add per-sdata station hash, and sdata hash greearb
2013-07-11 8:55 ` Johannes Berg
2013-07-11 15:29 ` Ben Greear
2013-07-26 8:53 ` Johannes Berg
2013-07-26 9:56 ` Felix Fietkau
2013-07-26 15:22 ` Ben Greear
2013-07-26 15:38 ` Felix Fietkau
2013-07-26 16:09 ` Ben Greear
2013-07-26 17:59 ` Felix Fietkau
2013-07-26 15:27 ` Ben Greear [this message]
2013-06-29 22:58 ` [WT PATCH 5/6] mac80211: Add debugfs for sdata and sdata->sta_vhash greearb
2013-06-29 22:58 ` [WT PATCH 6/6] mac80211: Tell user why beacons fail to parse greearb
2013-07-11 8:59 ` Johannes Berg
2013-07-11 15:10 ` Ben Greear
2013-07-11 15:17 ` Johannes Berg
2013-07-11 8:51 ` [WT PATCH 1/6] mac80211: Add debugfs file to show station-hash counts 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=51F29560.3080605@candelatech.com \
--to=greearb@candelatech.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/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).