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). -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
