All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC 1/2] mac80211:  Add vif hash for multi-station RX performance.
Date: Tue, 23 Apr 2013 15:06:24 -0700	[thread overview]
Message-ID: <517705E0.4070304@candelatech.com> (raw)
In-Reply-To: <5176E442.7070907@candelatech.com>

On 04/23/2013 12:42 PM, Ben Greear wrote:
> On 04/11/2013 02:19 AM, Johannes Berg wrote:

>> Another question: Have you thought about hashing the virtual interfaces
>> instead of the stations, and then hashing the stations inside each
>> virtual interface? That would make it a bit of a two-level thing:
>>
>> A1 (in the frame) -> virtual interface
>>      A2 (frame) -> station
>>
>> But it would address the TX side efficiently without "some_sta" since
>> you know the virtual interface there already, and could potentially have
>> less impact on the code? On TX it'd actually even be more efficient if
>> you have more than 1 station per interface (right now you don't though)
>
> This idea suddenly looks a lot more interesting.  The ieee80211_tx_status method needs
> to find the remote station & sdata, but in the AP case, the station hash works best,
> and in my many-sta-vif case, the VIF hash works best.  I don't see any way to guess
> which hash to use in this case.
>
> But, if we first hashed to find sdata, and then had a vif hash in the sdata
> object, the lookup should be fast for cases where the hash function works
> well.
>
> I'll give this a try...

Seems to mostly be working, but I've a few questions.

First, if we are hashing sdata on sdata->vif.addr, then we must
assume that everything in that hash has a unique MAC.  I'm
thinking that I would just never put monitor devices in
the hash.  Is there anything else that would cause problems
with this?

Second, the sta_info_get_bss call is found fairly often.  It
talks about finding a station on sdata or associated vlan.
Does this indicate that the there are VLAN sdata objects
with duplicate MACs?

I was hoping I could replace at least most calls to sta_info_get_bss
with one that just searched the new sdata->sta_hash hash table...

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


  reply	other threads:[~2013-04-23 22:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-03 16:48 [RFC 1/2] mac80211: Add vif hash for multi-station RX performance greearb
2013-04-03 16:48 ` [RFC 2/2] mac80211: Add vhash to debugfs greearb
2013-04-09  9:57 ` [RFC 1/2] mac80211: Add vif hash for multi-station RX performance Johannes Berg
2013-04-09 17:54   ` Ben Greear
2013-04-11  9:19     ` Johannes Berg
2013-04-11 16:11       ` Ben Greear
2013-04-23 19:42       ` Ben Greear
2013-04-23 22:06         ` Ben Greear [this message]
2013-04-24 11:01           ` 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=517705E0.4070304@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.