All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antonio Quartulli <antonio@open-mesh.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Thomas Pedersen <thomas@cozybit.com>,
	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: Mon, 18 Feb 2013 15:46:23 +0100	[thread overview]
Message-ID: <20130218144622.GA4162@open-mesh.com> (raw)
In-Reply-To: <1361197982.8555.24.camel@jlt4.sipsolutions.net>

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

On Mon, Feb 18, 2013 at 06:33:02 -0800, Johannes Berg wrote:
> On Mon, 2013-02-18 at 15:30 +0100, Johannes Berg wrote:
> > On Fri, 2013-02-15 at 18:19 +0100, Simon Wunderlich wrote:
> > 
> > > Commands we would like to propose are:
> > >  * start collecting - this feature should not run by default to avoid bloating memory for users who
> > >    don't even need this
> > >  * stop collecting
> > >  * read - dumps the data for all stations
> > >  * read + reset - dump the data and reset information for all stations. This should also clean up stations,
> > >    at least those which are not connected to the BSS, to not bloat the station table.
> > > 
> > > I guess the right position to implement this is mac80211 receive path. Our intended platform
> > > is ath9k/ath5k, but that feature should work with any mac80211 driver. We don't care if sta_info
> > > structs are allocated or custom structures are used, as long as we can receive a list of stations
> > > which includes peer and non-peer stations, along with their statistics.
> > > 
> > > We are looking forward to your thoughts. :)
> > 
> > I would argue that since most of the sta_info struct is used for
> > operational stuff, you shouldn't use it, but have a separate struct and
> > maybe embed that separate struct in sta_info for its statistics.
> > 
> > I'd also not use the existing nl80211 station APIs since this could be
> > an optional feature for many things, and it will likely break existing
> > expectations, e.g. that all stations listed by "iw wlan0 station dump"
> > are clients connected to an AP interface.
> > 
> > It could be argued that this API then should also not even include the
> > connected stations when listing ones, i.e. explicitly be non-connected
> > stations.
> 
> Or maybe use the APIs, but require including a special attribute in the
> dump/get request message in order to dump/get the/a non-connected
> station(s), and only include those attributes that are relevant.

In my current implementation I created a "twin hash-table". It contains
statistics for *all* the stations (peer and non-peer).

I think that instead of embedding this new struct (let's call it sta_stats) into
the sta_info one, it would be easier to let them be independent (this is why I
created the twin hash) and then create
a pointer from the sta_info to the related sta_stats.

For the API I think we should create a new nl80211 command.
If we simply add a
flag to the normal "station dump" command, we would not have all the attributes
to print (keep in mind station dump prints attributes that are in sta_info and
that are not in sta_stats).


Cheers,


-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

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

  reply	other threads:[~2013-02-18 14:47 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-15 17:19 [RFC] design discussion: Collecting information for (non-peer) stations Simon Wunderlich
2013-02-18 14:30 ` Johannes Berg
2013-02-18 14:33   ` Johannes Berg
2013-02-18 14:46     ` Antonio Quartulli [this message]
2013-02-18 15:29       ` Johannes Berg
2013-02-18 15:38         ` Antonio Quartulli
2013-02-18 15:43           ` Johannes Berg
2013-02-18 15:49             ` Antonio Quartulli
2013-02-18 15:58               ` Johannes Berg
2013-02-18 16:07                 ` Antonio Quartulli
2013-02-18 16:51                   ` Johannes Berg
2013-02-18 19:36                     ` Mathias Kretschmer
2013-02-20 17:19                     ` Simon Wunderlich
2013-02-20 19:10                       ` Thomas Pedersen
2013-02-21 17:19                         ` Simon Wunderlich
2013-02-19  9:32 ` Thomas Hühn
2013-02-20 17:49   ` Simon Wunderlich
2013-02-20 18:04   ` Mathias Kretschmer
2013-02-22 10:07 ` Zefir Kurtisi
2013-02-22 11:43   ` Simon Wunderlich
2013-02-22 12:34     ` Zefir Kurtisi
2013-02-22 16:21 ` Felix Fietkau
2013-02-22 16:36   ` Antonio Quartulli
2013-02-22 17:03     ` Felix Fietkau
2013-02-22 17:42       ` Adrian Chadd
2013-02-25 10:28         ` Simon Wunderlich
2013-03-08 14:13           ` Simon Wunderlich
2013-03-11 12:01             ` Zefir Kurtisi
2013-03-25 14:43               ` Simon Wunderlich
2013-02-22 17:42       ` Thomas Pedersen

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=20130218144622.GA4162@open-mesh.com \
    --to=antonio@open-mesh.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=marek@open-mesh.com \
    --cc=mathias.kretschmer@fokus.fraunhofer.de \
    --cc=simon.wunderlich@s2003.tu-chemnitz.de \
    --cc=thomas@cozybit.com \
    /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.