All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Ben Greear <greearb@candelatech.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC 1/2] mac80211:  Add vif hash for multi-station RX performance.
Date: Thu, 11 Apr 2013 11:19:28 +0200	[thread overview]
Message-ID: <1365671968.8272.35.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <516455CA.6070504@candelatech.com>

On Tue, 2013-04-09 at 10:54 -0700, Ben Greear wrote:

> >> +struct sta_info *sta_info_get_by_vif(struct ieee80211_local *local,
> >> +				     const u8 *vif_addr, const u8 * sta_addr) {
> >> +	struct sta_info *sta;
> >> +
> >> +	sta = rcu_dereference_check(local->sta_vhash[STA_HASH(vif_addr)],
> >> +				    lockdep_is_held(&local->sta_mtx));
> >> +	while (sta) {
> >> +		if (ether_addr_equal(sta->sdata->vif.addr, vif_addr) &&
> >> +		    ether_addr_equal(sta->sta.addr, sta_addr))
> >> +			break;
> >> +		sta = rcu_dereference_check(sta->vnext,
> >> +					    lockdep_is_held(&local->sta_mtx));
> >
> > Almost all of your rcu_dereference_check() invocations should be
> > rcu_dereference_protected(). See include/linux/rcupdate.h :)
> 
> Now this, I'm not so sure of.  That rcu_dereference_protected seems to
> be only used for the 'update-side' use.  I was under the impression
> that when the mac80211 rx logic is called we are only protected by rcu,
> not the update mutex.

Ah, yes, I was reading this the wrong way, sorry. Here the _check() is
correct of course -- you want to be either under RCU protection or hold
the sta_mtx.

> I also struggle to understand RCU properly...so maybe I'm just
> wrong about all that...
> 
> The other methods to get sta_info around that code use the _check() variant,
> by the way...

Yeah ... :)

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)

johannes


  reply	other threads:[~2013-04-11  9:19 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 [this message]
2013-04-11 16:11       ` Ben Greear
2013-04-23 19:42       ` Ben Greear
2013-04-23 22:06         ` Ben Greear
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=1365671968.8272.35.camel@jlt4.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=greearb@candelatech.com \
    --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.