Return-path: Received: from mail-bw0-f222.google.com ([209.85.218.222]:60163 "EHLO mail-bw0-f222.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753083AbZETNnG (ORCPT ); Wed, 20 May 2009 09:43:06 -0400 Received: by bwz22 with SMTP id 22so414959bwz.37 for ; Wed, 20 May 2009 06:43:06 -0700 (PDT) From: Helmut Schaa To: Johannes Berg Subject: Re: Scan while TX/RX'ing a lot of data Date: Wed, 20 May 2009 15:43:11 +0200 Cc: "Luis R. Rodriguez" , Dan Williams , "linux-wireless" , Aeolus.Yang@atheros.com, Senthil Balasubramanian , Gaurav.Jauhar@atheros.com, David Miller , Jouni Malinen References: <43e72e890905141052o1f072bc5m4bc5922327617f8b@mail.gmail.com> <200905201341.47185.helmut.schaa@gmail.com> <1242819888.19216.6.camel@johannes.local> In-Reply-To: <1242819888.19216.6.camel@johannes.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200905201543.12717.helmut.schaa@gmail.com> Sender: linux-wireless-owner@vger.kernel.org List-ID: 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