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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
