On Thu, 2014-09-18 at 11:19 +0530, Sujith Manoharan wrote: > I can see your point and agree that the original intention of the > mgd_prepare_tx() > callback is as described in the documentation. But with multiple active > contexts, flush() becomes a big hammer rather than a simple emptying of > the queues. :-)
I'm a bit conflicted about this. If we add mgd_prepare_tx() here, what's to say that we don't need to also do this for a variety of other frames? Like sending delBA action frames? I guess the difference would be that we don't disassoc immediately in those case. However, if you consider deauth/flush while you're on a different context, then mgd_prepare_tx() would potentially not really be sufficient either. If that forces or waits for a context switch, you really have no guarantee that the deauth frame went out because it might be waiting behind other frames, and there's nothing that guarantees enough time in the context slice to actually send out all of them ... In that sense, I think you still have to implement flush. But I also think you see it wrongly - you don't have to force a context switch in flush, flush can essentially be "wait for queue to be empty" and the context switching etc. happens in the background. mgd_prepare_tx() is, the way I see it, really more for the case where you really have no context scheduling *at all* and have to somehow send a frame anyway. In the case we're talking about you have regular context scheduling, and there shouldn't be a need to add a special scheduling on top. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
