From: Luca Coelho <luca@coelho.fi>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
Johannes Berg <johannes@sipsolutions.net>,
sw@simonwunderlich.de, "Otcheretianski,
Andrei" <andrei.otcheretianski@intel.com>
Subject: Re: [RFC v2 3/4] mac80211: allow reservation of a running chanctx
Date: Mon, 03 Mar 2014 12:37:49 +0200 [thread overview]
Message-ID: <1393843069.13669.86.camel@dubbel> (raw)
In-Reply-To: <1393840630.13669.82.camel@dubbel>
On Mon, 2014-03-03 at 11:57 +0200, Luca Coelho wrote:
> Hi Michał,
>
> I had a new idea.
>
>
> On Fri, 2014-02-28 at 17:31 +0200, Luca Coelho wrote:
> > But seriously, I'm almost fully convinced your approach is better. I'll try to spin without the RESERVED mode.
> >
> > But that probably will only happened Monday, because I'm already spinning down for the weekend.
>
> What about this: when we are reserving the chanctx, even if we're the
> only ones in it (and thus will change it on-the-fly), we increase the
> refcount. This means that we would have refcount == 2, even though
> we're the only users, but that's aligned with what happens when we
> reserve a different chanctx.
>
> When we use the reservation, we do exactly the same thing as if we were
> moving to a new chanctx, but add a intermediate step where we check if
> the old ctx has refcount 0, in which case we change its channel:
>
> Reserving our own chanctx for future change:
>
> 1. new_ctx = old_ctx;
> 2. increase new_ctx.refcount (new.refcount == 2, old.refcount == 2);
>
>
> Using the reservation:
>
> 1. unassign the vif from the old chanctx (old.refcount == 1,
> new.refcount == 1);
> 2. we decrease the refcount of the new chanctx (new.refcount == 0,
> old.refcount == 0);
> 3. if (old.refcount == 0) means we were the only user, change channel;
> 4. we assign ourselves to the new chanctx (new.refcount == 1 again);
>
>
> This would make this whole thing pretty generic with only one extra if
> for the on-the-fly chanctx change case.
>
> If more vifs came and are changing the chanctx at the same time, it will
> be fine too because the channel will only change when the last reserver
> uses the reservation.
>
> Does this make sense?
Oh wait, this last part won't work with multiple vifs changing at the
same time, because in that case the refcount will never be 0. I guess
instead of checking if old.refcount == 0, we should check if the old_ctx
and new_ctx are identical. The first vif to get here will change the
channel and the other ones will NOP because the channel they want is
already the current channel of the chanctx.
Let me try to do this.
--
Luca.
next prev parent reply other threads:[~2014-03-03 10:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-27 14:41 [RFC v2 0/4] mac802111: channel context reservation (was: multi-vif/multi-channel CSA implementation) Luca Coelho
2014-02-27 14:41 ` [RFC v2 1/4] mac80211: split ieee80211_vif_change_channel in two Luca Coelho
2014-02-27 14:41 ` [RFC v2 2/4] mac80211: implement chanctx reservation Luca Coelho
2014-02-27 15:16 ` Michal Kazior
2014-02-28 11:48 ` Luca Coelho
2014-02-27 14:41 ` [RFC v2 3/4] mac80211: allow reservation of a running chanctx Luca Coelho
2014-02-27 15:29 ` Michal Kazior
2014-02-28 12:17 ` Luca Coelho
2014-02-28 12:56 ` Michal Kazior
2014-02-28 13:41 ` Luca Coelho
2014-02-28 14:07 ` Michal Kazior
2014-02-28 14:32 ` Luca Coelho
2014-02-28 14:55 ` Michal Kazior
2014-02-28 15:31 ` Luca Coelho
2014-03-03 9:57 ` Luca Coelho
2014-03-03 10:37 ` Luca Coelho [this message]
2014-03-03 10:38 ` Michal Kazior
2014-03-03 12:37 ` Luca Coelho
2014-03-03 13:26 ` Michal Kazior
2014-03-03 13:42 ` Luca Coelho
2014-03-03 13:57 ` Michal Kazior
2014-02-27 14:41 ` [RFC v2 4/4] mac80211: add usage of CS channel reservation for STA Luca Coelho
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=1393843069.13669.86.camel@dubbel \
--to=luca@coelho.fi \
--cc=andrei.otcheretianski@intel.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=michal.kazior@tieto.com \
--cc=sw@simonwunderlich.de \
/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).