On Mon, 2009-05-18 at 11:06 -0700, Luis R. Rodriguez wrote: > > No, I just think we should, if associated, spread out the scan a little > > more, and not change anything in the userspace API at all, just change > > the time it takes to do the scan and allow data to pass by going back to > > the operational channel. > > If we enhance scanning in mac80211 while your associated by relying > on some metrics we're leaving userspace out of the decision. It would > seem nicer to expose these metrics to userspace so it can take a > better informed decision. The issue still remains with old wext unless > are OK with some defaults. Which is why I was suggesting a SMART_WEXT. > But it seems we are OK with penalizing a userspace wext scan by > delaying it quite a bit when associated at the expense of doing > scattered scan. We would also do that with a nl80211 scan, if it was requested for all channels. I don't see how we are leaving userspace out of the decision either. Yes, we're not asking userspace in which order to scan (actually nl80211 order is used but we don't guarantee that) or how many channels to scan between traffic etc. However, all this information doesn't belong into the scan command. That would mean applications would not only have to register their requirements with the kernel but also with the scanning applications! Which would be a completely hopeless approach! Yes, having userspace influence policy on these things is great, but it also needs to have a chance to do something sane! > Hm, yeah I just noticed we don't rx flush on channel change... I do > see this notice on ath_set_channel() > > /* XXX: do not flush receive queue here. We don't want > * to flush data frames already in queue because of > * changing channel. */ > > I forget why we added that now.. Anyway I guess we can test something like this: > > diff --git a/drivers/net/wireless/ath/ath9k/main.c > b/drivers/net/wireless/ath/ath9k/main.c > index bbbfdcd..a5db284 100644 > --- a/drivers/net/wireless/ath/ath9k/main.c > +++ b/drivers/net/wireless/ath/ath9k/main.c > @@ -261,6 +261,11 @@ int ath_set_channel(struct ath_softc *sc, struct > ieee80211_hw *hw, > ath9k_hw_set_interrupts(ah, 0); > ath_drain_all_txq(sc, false); > stopped = ath_stoprecv(sc); > + ath_flushrecv(sc); > + > + spin_lock_bh(&sc->rx.rxflushlock); > + ath_rx_tasklet(sc, 0); > + spin_unlock_bh(&sc->rx.rxflushlock); > > /* XXX: do not flush receive queue here. We don't want > * to flush data frames already in queue because of > > > > But not quite sure if this would resolve that race you mention of. I don't think so, no. > > Then again I don't quite see why we discard frames received during a > > scan even if they were for us. > > We do discard them? Yes. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
