linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <lrodriguez@atheros.com>
To: Ben Greear <greearb@candelatech.com>
Cc: "Luis R. Rodriguez" <mcgrof@gmail.com>,
	"ath9k-devel@venema.h4ckr.net" <ath9k-devel@venema.h4ckr.net>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [ath9k-devel] [PATCH 3/3] ath9k: Keep track of stations for debugfs.
Date: Thu, 6 Jan 2011 18:49:09 -0800	[thread overview]
Message-ID: <20110107024909.GD20431@tux> (raw)
In-Reply-To: <4D267E4D.7000608@candelatech.com>

On Thu, Jan 06, 2011 at 06:45:33PM -0800, Ben Greear wrote:
> On 01/06/2011 06:30 PM, Luis R. Rodriguez wrote:
> > On Thu, Jan 6, 2011 at 4:46 PM,<greearb@candelatech.com>  wrote:
> >> +#define ATH9K_MAX_STATIONS 1024
> >
> > How about making this a Kconfig with a default to a value of the known
> > (by you) max workable number of STAs that one can use on ath9k, which
> > is modifiable to other values by power of two up to 1024. Advise in
> > the kconfig that if more STAs are used then some issue may arise but
> > should be reported (so the issue can be fixed). This way by default
> > normal users (you're not normal) won't enable>  max known workable
> > stable number of STAs on ath9k.
> 
> This is just for debugging at this point.  It wastes a bit of memory
> when debugfs is enabled, but otherwise doesn't affect anything.  It's
> not even really a problem if there are more stations than fit in
> the array.

I meant to use the value as a limit on the # of STAs you can create
with one ath9k device. The debugfs can still be used as you did,
only that the limit would come from the kconfig value.

> I can reproduce all my problems with < 128, so if you'd prefer
> the number be smaller, that's fine with me.  I don't think it's
> worth a configurable value, however.

I thikn we should limit the # STAs to whatever it is that you can
use in a realiable way, this should be a driver limitation, but
I figured you'd want to configure this to a higher value yourself
for whatever tests you are doing. We should fix it though but at
least other clueless users would not go over stable limit you have
found.

  Luis

  reply	other threads:[~2011-01-07  2:49 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-07  0:46 [PATCH 1/3] ath9k: Decrease skb size to fit into one page greearb
2011-01-07  0:46 ` [PATCH 2/3] ath9k: Re-start xmit logic in xmit watchdog timer greearb
2011-01-07  6:51   ` Vasanthakumar Thiagarajan
2011-01-07  7:16     ` Ben Greear
2011-01-07 15:11     ` [ath9k-devel] " Peter Stuge
2011-01-07 15:19       ` Ben Greear
2011-01-07 15:20       ` Vasanthakumar Thiagarajan
2011-01-07  0:46 ` [PATCH 3/3] ath9k: Keep track of stations for debugfs greearb
2011-01-07  2:30   ` [ath9k-devel] " Luis R. Rodriguez
2011-01-07  2:45     ` Ben Greear
2011-01-07  2:49       ` Luis R. Rodriguez [this message]
2011-01-07  3:17         ` Ben Greear
2011-01-07 15:36           ` Peter Stuge
2011-01-07 15:52             ` Ben Greear
2011-01-07 20:01             ` Luis R. Rodriguez
2011-01-07 20:25               ` Luis R. Rodriguez
2011-01-07 20:30                 ` Luis R. Rodriguez
2011-01-07 19:46           ` Luis R. Rodriguez
2011-01-07  2:45   ` Felix Fietkau
2011-01-07  2:48     ` Ben Greear
2011-01-07  0:57 ` [ath9k-devel] [PATCH 1/3] ath9k: Decrease skb size to fit into one page Luis R. Rodriguez
2011-01-07  1:03   ` Ben Greear
2011-01-07  1:04 ` Christian Lamparter
2011-01-07  1:23   ` Eric Dumazet
2011-01-07  1:57     ` Luis R. Rodriguez
2011-01-07  2:07       ` Eric Dumazet
2011-01-07  2:13         ` Luis R. Rodriguez
2011-01-07  2:24           ` Eric Dumazet
2011-01-07  2:33             ` Eric Dumazet
2011-01-07 10:58 ` Johannes Berg
2011-01-07 18:34   ` Ben Greear
2011-01-07 20:09     ` [ath9k-devel] " Luis R. Rodriguez
2011-01-07 20:26       ` Eric Dumazet
2011-01-07 22:20         ` Ben Greear
2011-01-07 22:26           ` Eric Dumazet
2011-01-07 22:46             ` Ben Greear
2011-01-09  9:34               ` 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=20110107024909.GD20431@tux \
    --to=lrodriguez@atheros.com \
    --cc=ath9k-devel@venema.h4ckr.net \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mcgrof@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).