Am Mittwoch, 20. Mai 2009 schrieb Johannes Berg: > On Wed, 2009-05-20 at 13:41 +0200, Helmut Schaa wrote: > > Am Dienstag, 19. Mai 2009 schrieb Johannes Berg: > > > On Mon, 2009-05-18 at 15:43 +0200, Helmut Schaa wrote: > > > > > > One solution would be to force all drivers to report the tx status. Another > > > > one would be to just wait until the device's queue is empty. At that point > > > > we know that all pending data frames were sent out and additionally the > > > > nullfunc frame was also sent out, so we can safely switch to the next > > > > to-be-scanned channel. > > > > > > Some drivers now flush queues at channel switch time, but there's no way > > > to guarantee that the software queues are actually empty and the > > > nullfunc frame isn't queued up behind other traffic. Also, waiting for > > > any driver to report a status will lead to problems because the driver > > > might just have dropped the frame for various reasons like being out of > > > memory. > > > > Hmm, the problem is basically (from a mac80211 perspective) that the > > mdev tx queue could still contain data frames when the nullfunc frame > > gets queued, right? And we do not assure that these frames are sent > > out before the channel switch. > > > > Hence, would it be possible to: > > 1) Stop all sub_if tx queues (afterwards no new data frames should > > appear in the mdev tx queue) > > 2) Queue the nullfunc frame > > 3) Flush the mdev's tx queue > > 4) Switch the channel > > ? > > I don't think that is sufficient, Maybe not sufficient, but it's at least an improvement. > unless the driver also flushes the > hardware queue at channel switch time. Yes, but that would be the drivers responsibility and could be fixed in a second step. > Which we may want to make explicit with a new callback or so? And make it mandatory? Helmut -- 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
