James Ketrenos wrote:
Jeff Garzik wrote:
James Ketrenos wrote:
Jeff Garzik wrote:
James Ketrenos wrote:
That said -- if the driver can execute in parallel to the stack for
some operations, shouldn't they remain on their own workqueues so
the work can be divided up vs. having *everything* routed through
one singlethread workqueue?
Just because it -can-, does not mean it should.
Unless there is a -proven- need for the operations to be parallel,
you should avoid the burden of such complexity.
There is no additional complexity by having the driver create its own
workqueue; it just calls create_workqueue during probe and
destroy_workqueue during remove.
That is obviously false. Ignoring the additional code and memory
usage, you must additionally evaluate the potential for deadlocks and
races.
So you're saying that by using mac80211's workqueue a driver no longer
has to worry about any deadlocks or race conditions? That is obviously
false.
Don't be dense. If two operations are guaranteed to go down the same
pipeline, then there is a clear sequence guarantee that is not present
if operations are [needlessly] parallel.
I didn't say we can't use mac80211's workqueue if it was
created/destroyed during alloc/free vs. hw register.
I asked a question about if work can execute in parallel, shouldn't we
let it
Without justification for the additional complexity, the answer is no.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
