[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-wireless
Subject:    Re: [RFC v2] basic background scan
From:       Helmut Schaa <hschaa () suse ! de>
Date:       2008-09-24 16:07:58
Message-ID: 200809241807.58687.hschaa () suse ! de
[Download RAW message or body]

Am Mittwoch, 24. September 2008 17:59:01 schrieb Johannes Berg:
> On Wed, 2008-09-24 at 17:55 +0200, Helmut Schaa wrote:
> 
> > > What I meant to say is that it'll give problems with drivers that don't
> > > do status reporting properly, and what are you going to do when one of
> > > them fails anyway? retry it? how long? assume the connection was lost if
> > > it isn't acked? I see little point in it to start with.
> > 
> > The main reason why I'd like to know when the frame was acked is that it might 
> > happen (and it did happen in my tests already) that the frame notifying the 
> > AP about entering power save state wasn't send before switching to another 
> > channel. Hence the AP won't buffer any frames for us.
> 
> We should make these frames able to "skip the queue" so to speak, that
> would be smarter either way.

Agreed. That would at least enhance the probability that the frame is sent
out fast enough.

> > > > > > +				netif_tx_wake_all_queues(sdata->dev);
> > > > >
> > > > > This is worsening a problem we already have -- you can enable queues
> > > > > that the driver asked to be disabled. Until we fix that, I don't think
> > > > > we should tempt our luck even more.
> > > >
> > > > I see! That's really problematic.
> > > > Do you have already an idea on how to fix it?
> > >
> > > Not really; introduce bits somewhere to keep track of who wants to
> > > enable/disable queues I guess.
> > 
> > A first trivial solution would be to just store which queues are active
> > when the scan is started and restarting only these queues after the scan
> > completed.
> 
> Actually, well, you have to deal with drivers like adm8211 that
> stop/start the queues for each packet...

Oops. I did not know about drivers behaving like that
=> have to find a better way to deal with starting/stopping queues.

Thanks,
Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]