public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: reinette chatre <reinette.chatre@intel.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "linville@tuxdriver.com" <linville@tuxdriver.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 1/2] cfg80211: initialize rate control after station inserted
Date: Mon, 31 Aug 2009 10:07:31 -0700	[thread overview]
Message-ID: <1251738451.13180.14.camel@rc-desk> (raw)
In-Reply-To: <1251538470.19422.23.camel@johannes.local>

Hi Johannes,

On Sat, 2009-08-29 at 02:34 -0700, Johannes Berg wrote:
> I'd say we do the following: At startup, we program the broadcast STA
> into the device so we always have that, and do that synchronously so if
> that fails for some stupid reason. I think we already do that.

The station management in the driver is not entirely synchronous. That
is, adding a station and removing a station are not the only two
commands affecting the device's station knowledge. The often used "rxon"
command, when used without the association flag, always clears the
station table. This command is used frequently while not associated. So,
knowing when to add the broadcast station is not exact and is the reason
why it is currently done as part of the sending of the rxon command.
What I have been doing as part of testing here was to have a new
"restore stations" call which is called after sending the rxon command
to get device and driver in sync again wrt station management. If we
include something like this in the driver then it will be possible to
implement your proposal to add the broadcast station at the beginning.

> Then, we use a station private area that mac80211 can allocate for us to
> store the STA_ID for each station. Set this to the broadcast STA ID,
> which is always valid in some sense, at sta_notify(add) time. Then,
> asynchronously, tell the device about the station. Once that command
> finishes, look up the sta struct again and set the STA_ID to the new ID
> that we used in the device. This way, a sta struct will always have a
> valid sta ID in it.
> 
> Now, when we need to set a key for a station, we actually get the
> station struct. Thus, we can keep two separate flag in the station
> struct that tells us whether the STA_ADD was successful. If this flag is
> unset, then we reject the add_key with -ENOSPC. Or when we detect that
> the key command was too fast after the sta_notify we can wait for the
> ADD_STA to finish in the key notification since that can sleep.
> 
> And then rate stuff we can just also do as part of the async sta add
> command, so that the sta ID is only set after we have the sta programmed
> into the device and also initialised rate control properly for it.
> Ultimately the rate control algorithm could do nothing at all, and then
> we can remove it completely.

Thank you very much for these great suggestions. I'll look into this
implementation.

Reinette




      reply	other threads:[~2009-08-31 17:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-27 23:34 [PATCH 1/2] cfg80211: initialize rate control after station inserted Reinette Chatre
2009-08-27 23:34 ` [PATCH 2/2] mac80211: " Reinette Chatre
2009-08-28  7:45 ` [PATCH 1/2] cfg80211: " Johannes Berg
2009-08-28 15:45   ` reinette chatre
2009-08-28 21:01     ` Johannes Berg
2009-08-28 21:26       ` Luis R. Rodriguez
2009-08-28 21:40       ` Tim Gardner
2009-08-29  5:22         ` Kalle Valo
2009-08-29  9:01         ` Johannes Berg
2009-08-28 22:18       ` reinette chatre
2009-08-29  9:34         ` Johannes Berg
2009-08-31 17:07           ` reinette chatre [this message]

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=1251738451.13180.14.camel@rc-desk \
    --to=reinette.chatre@intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.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