scanning question

scanning question

[Chuck Tuffli]

I'm implementing a mac80211 driver and have a question about the
expected behavior during software based scanning. Can the driver
assume that mac80211 won't start a scan until all previous TX
complete? If not, what is the expected behavior of the driver? Finish
current TX before starting the scan? Drop current TX? Something else?
TIA!

---chuck

Re: scanning question

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

On Wed, 2009-11-18 at 17:42 -0800, Chuck Tuffli wrote:
> I'm implementing a mac80211 driver and have a question about the
> expected behavior during software based scanning. Can the driver
> assume that mac80211 won't start a scan until all previous TX
> complete? If not, what is the expected behavior of the driver? Finish
> current TX before starting the scan? Drop current TX? Something else?
> TIA!

No, you can't assume that right now, unfortunately. We've been wanting
to implement a flush_tx() callback for a long time now but nobody did so
far. Some drivers might flush in the pre_scan() callback, but I think
that isn't actually correct because the nullfunc frame we might send
might pass other frames on the hw queues/fifos.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: scanning question

[Chuck Tuffli]

On Thu, Nov 19, 2009 at 2:56 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2009-11-18 at 17:42 -0800, Chuck Tuffli wrote:
>> I'm implementing a mac80211 driver and have a question about the
>> expected behavior during software based scanning. Can the driver
>> assume that mac80211 won't start a scan until all previous TX
>> complete? If not, what is the expected behavior of the driver? Finish
>> current TX before starting the scan? Drop current TX? Something else?
>> TIA!
>
> No, you can't assume that right now, unfortunately. We've been wanting
> to implement a flush_tx() callback for a long time now but nobody did so
> far. Some drivers might flush in the pre_scan() callback, but I think
> that isn't actually correct because the nullfunc frame we might send
> might pass other frames on the hw queues/fifos.

OK. I agree that flushing isn't ideal, so the alternative is for
someone to wait until IO finishes.

Can the driver sleep until it is ready to scan (I'm guessing no)?

Alternatively, could we modify scan.c such that if a driver returned
EAGAIN in sw_scan_start, the scan would wait in a similar way to what
happens if something is on the work_list?

Re: scanning question

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

On Thu, 2009-11-19 at 07:49 -0800, Chuck Tuffli wrote:

> > No, you can't assume that right now, unfortunately. We've been wanting
> > to implement a flush_tx() callback for a long time now but nobody did so
> > far. Some drivers might flush in the pre_scan() callback, but I think
> > that isn't actually correct because the nullfunc frame we might send
> > might pass other frames on the hw queues/fifos.
> 
> OK. I agree that flushing isn't ideal, so the alternative is for
> someone to wait until IO finishes.

I think we should actually flush the queues.

> Can the driver sleep until it is ready to scan (I'm guessing no)?

Yes, pre_scan() can sleep, and a flush() callback would also be able to
sleep.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]