[PATCH 7/8] GAS: End remain-on-channel due to delayed GAS comeback request

[Peer, Ilan]

> -----Original Message-----
> From: Jouni Malinen [mailto:j at w1.fi]
> Sent: Sunday, December 20, 2015 22:36
> To: Peer, Ilan
> Cc: hostap at lists.infradead.org; Gottlieb, Matti
> Subject: Re: [PATCH 7/8] GAS: End remain-on-channel due to delayed GAS
> comeback request
> 
> On Sun, Dec 20, 2015 at 07:55:48PM +0200, Jouni Malinen wrote:
> > I fixed that by keeping the query->offchannel_tx_started tracking
> > up-to-date with patch 7/8 behavior and using the longer wait time for
> > the first comeback request if the initial wait time had been canceled
> > (which it really is in every single case now, but that could be
> > modified to consider the fragmentation-without-wait case with very
> > short comeback delay to skip stopping the initial ROC). This provides
> > significant further speedup when both patches 7 and 8 are applied.
> 
> That special case of fragmentation (comeback delay 1) is now handled without
> stopping the initial ROC.
> 
> > To make it acceptable to test with shorter wait time first, I added a
> > mechanism to retry full GAS sequence if any waits for a comeback
> > response fail. This second attempt will use the old timeout of 1000 ms.
> > With this, the end result is actually more robust than the previous
> > design and significantly faster for the fragmented case with drivers
> > that cannot extend pending ROC. I haven't yet pushed this into the
> > master branch, but if nothing unexpected shows up, I'll probably do so.
> 
> I pushed this with a fixed patch 8/8 into the master branch. It is not exactly
> perfect since an exchange taking more than 850 ms will end up in the state
> where each new TX operation hits the issue of the pending ROC ending up
> sooner. That said, this is significantly faster than what was there previously and
> I'm not sure there would be sufficient justification for the extra complexity
> within wpa_supplicant to try to track the remaining ROC duration within
> kernel (i.e., if someone wants to optimize that, it might be better to spend the
> effort working on kernel side making it possible to extend the ongoing ROC
> and/or providing more convenient events to user space to indicate when the
> wait for an offloaded TX operation has completed in a way that would benefit
> from wpa_supplicant requesting a longer duration for the next TX command).
> 

I do not think that this should be handled in wpa_supplicant, as even today drivers behave
differently when it comes for handling ROC operations, i.e., mac80211 SW ROC vs. HW ROC,
and this would over complicate wpa_s. I think that that if this would be needed a better apparoch
would be moving the ROC scheduling policy further down to the hardware were possible (for
example for HWs already need to handle MCC etc.).

Thanks for optimizing this :)

Ilan.