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, unless the driver also flushes the hardware queue at channel switch time. Which we may want to make explicit with a new callback or so? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
