> -----Original Message----- > From: Jouni Malinen [mailto:j@xxxxx] > Sent: Sunday, December 20, 2015 22:36 > To: Peer, Ilan > Cc: hostap@xxxxxxxxxxxxxxxxxxx; 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. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
