ether_input question

[Aniruddha Bohra]

Robert Watson wrote:
> On Fri, 16 Mar 2007, Aniruddha Bohra wrote:
>> My question is : Does ether_input() assume it is the only thread 
>> executing the code? If it is the case, what is the reason for 
>> dropping the lock in the DEVICE_POLLING case?
>
> I can't speak to the details of the above, but can speak generally on 
> the issue of the link layer input path and locking.  There is no 
> assumption that the caller will provide serialization, and fully 
> concurrent input from multiple threads is supported.  The reason the 
> drivers drop their locks is that the network stack frequently holds 
> locks over calls to driver output routines.  As a result, driver locks 
> tend to follow network stack locks in the lock order--at least, for 
> drivers that have a single lock covering both send and receive paths 
> (quite common).  As a result, the driver must drop the driver lock 
> before calling into the stack to avoid a lock order reversal.

Thanks Robert,
  So, if I have a queue shared between ether_input() and another thread, 
I need to
ensure mutual exclusion. In such scenarios, should spinlocks or default 
mutexes be
used?

  The driver locks themselves are usually MTX_DEF, whereas in netgraph 
for example,
(the scenario above), a spinlock is used. Is there a rule of thumb, for 
example, never use
blocking locks in the network interrupt path?

Thanks
Aniruddha