Date: Fri, 16 Mar 2007 09:47:59 -0400 From: Aniruddha Bohra <bohra@nec-labs.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-net@FreeBSD.org Subject: Re: ether_input question Message-ID: <45FAA00F.4070208@nec-labs.com> In-Reply-To: <20070316141836.J60288@fledge.watson.org> References: <45FA98DD.3080205@cs.rutgers.edu> <20070316141836.J60288@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45FAA00F.4070208>