Re: [PATCH] Add iwlwifi wireless drivers

[Jeff Garzik <jeff@garzik.org>]

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