On 3 March 2014 10:57, Luca Coelho <luca@xxxxxxxxx> 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);
I was thinking of doing it like this.
> 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);
I didn't really consider unassigning vif from chanctx like that (since
the original single-channel channel non-chanctx hw doesn't do that).
If you assume it is safe to unassign the vif then the logic seems
plausible. I like it.
> This would make this whole thing pretty generic with only one extra if
> for the on-the-fly chanctx change case.
I'd rather call it "in place" 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?
Does the following match your idea of multi-vif reservation with the
refcount idea?
[2 vifs on chanctx->refcount==2]
* vif1 reserve (refcount==3)
* vif2 reserve (refcount==4)
* vif1 use reservation: (refcount==3)
* stop queues
* unassign vif (refcount==2)
* since refcount!=0 do nothing more
* vif3 use reservation: (refcount==1)
* unassign vif (refcount==0)
* since refcount==0 do:
* chanctx channel change
* vif1 assign (refcount==1)
* vif2 assign (refcount==2)
* wake queues
Additionally you'd have to check after each "use reservation": if all
vifs with matching reserved_chanctx have no assigned chanctx but the
reserved_chanctx->refcount > 0, then disconnect all vifs with the
matching reserved_chanctx.
Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
