Re: [RFC] design discussion: Collecting information for (non-peer) stations

From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
To: Thomas Pedersen <thomas@cozybit.com>
Cc: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>,
	Johannes Berg <johannes@sipsolutions.net>,
	Antonio Quartulli <antonio@open-mesh.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Marek Lindner <marek@open-mesh.com>,
	Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Subject: Re: [RFC] design discussion: Collecting information for (non-peer) stations
Date: Thu, 21 Feb 2013 18:19:34 +0100	[thread overview]
Message-ID: <20130221171934.GA6662@pandem0nium> (raw)
In-Reply-To: <CAG6hwVPF_kvqCOtWJTWpLChOGbo+P8Du=y6Js0MDiF19_QR=ag@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

On Wed, Feb 20, 2013 at 11:10:14AM -0800, Thomas Pedersen wrote:
> Hi Simon,
> 
> On Wed, Feb 20, 2013 at 9:19 AM, Simon Wunderlich
> <simon.wunderlich@s2003.tu-chemnitz.de> wrote:
> 
> > To sum from this discussion (I think it's a good idea):
> >
> >  * embed the stats_entry into the sta_info
> >  * update peer-stats by modifying the embedded stats_entry (we do the lookup anyway
> >  * keep the non-peer stats in a seperate hash, and only keep stats_entry for them (we don't need
> >    the full sta_info after all).
> >
> > We should consider some corner cases here, e.g. adding stas, then we have to
> > copy+remove the stats from the non-peer hash, or removing stas, then we have
> > to copy the so-far collected stats to the non-peer hash.
> >
> > If you are okay with it, we can use the NL80211_CMD_GET_STATION command
> > (as in iw station dump), and add a seperate flag to give info for non-peer sta.
> >
> > What about the other commands I suggested (read+reset, start, stop)? For read+reset,
> > we could just send yet another flag (RESET_STATS) with the GET_STATION command, but
> > for start/stop we would need new commands? Or would you have any better idea?
> >
> > @Thomas: Is there anything to consider for 802.11s?
> 
> I can't think of anything that would be specifically useful for
> 802.11s right now, and we can always extend the statistics in the
> future. One case where this might be useful is if the driver has a
> limited number of station slots, the MPM could monitor neighbor
> stations for a more "suitable" peer candidate, but your existing stats
> should cover that.

OK, that sounds good. If there are any other requirements we should consider,
please let us know.

> 
> Turning on this feature would add some sort of (internal to mac80211)
> monitor interface, or just disable all frame filters on a given PHY?
> How does it work now?

Right now we use a monitor interface to get frames from other BSS and
signal info via radiotap. I'm not sure yet if any "virtual" monitor
interface or disabling RX filters is required. If anyone has a good idea
please let me know, otherwise I will try out.

Thanks,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]