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

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

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

Hello Zefir,

On Fri, Feb 22, 2013 at 11:07:46AM +0100, Zefir Kurtisi wrote:
> On 02/15/2013 06:19 PM, Simon Wunderlich wrote:
> > Hello wireless folks,
> > 
> > Mathias Kretschmer and me would like to bring another new feature to the kernel:
> > Collecting information for (non-peer) stations. [...]
> > 
> > Cheers,
> >         Simon
> > 
> Hi Simon,
> 
> our areas of operations obviously highly overlap, since I did the same
> consideration path only recently ;)
> 
> For the frequency planning feature we are currently working on, I need those
> extended statistics you are proposing with additional filtering rules (OUI or mask
> based) to classify peers.
> 
> My initial idea was to do a sliding time window aggregation of those statistics in
> the kernel with almost the same interface to the userspace you are proposing.
> 
> But with your integration of the spectral feature I realized how efficient relay
> based continuous data transfer is (as compared to sending samples over netlink).
> Consequently I revised the initial plan and consider realizing the extended
> statistics collection in userspace.
> 
> The modifications required in the kernel are minimal:
> * create relay file in debugfs
> * provide enable flag in debugfs
> * based on this flag, extract relevant information from frames and write to relay
> 
> This way, you move complexity out of the kernel and maximize flexibility for
> statistical evaluation in userspace. Also, the overhead for moving data between
> kernel and userspace is minimized, since you do them in bulk.
> 
> This is all in the planning phase, so I have no proof-of-concept patches yet.
> Would just like to hear what your thoughts are and whether this could be the way
> to go.

it is nice to hear that the relayfs approach works well. :)

Our biggest performance issue is probably the syscall for every packet, so minimizing
data to be sent to userspace and aggregate it to would benefit to our performance
problem.

I would also agree that this approach is simpler as we don't have to manage lists
of clients and purge them. And we can evaluation in userspace, just as everyone
needs for its application (maybe some of these statistics are not of general interest).

Issues I see are:
 * the relayfs has to be regularly polled for new data (maybe multiple times a second),
   so it can't overflow. I'm just looking at a dump from a running iperf test, it shows
   ~12000 packets per second (at 70Mbit/s). Assuming we are sending 64 byte of metainfo
   per packet, this would sum up to 768k every second. Doing the statistics computation
   in userspace makes no difference to doing it in kernelspace, imho.
 * in-kernel drivers can't use the gathered statistics (that would affect 802.11s)
 * I wonder how debugfs use in mac80211 for this kind of feature is acceptable. This
   would be a question for Johannes. :)

Thanks for sharing your thoughts!

Cheers,
	Simon

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