Date: Fri, 16 Mar 2007 14:21:25 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Aniruddha Bohra <bohra@cs.rutgers.edu> Cc: freebsd-net@freebsd.org Subject: Re: ether_input question Message-ID: <20070316141836.J60288@fledge.watson.org> In-Reply-To: <45FA98DD.3080205@cs.rutgers.edu> References: <45FA98DD.3080205@cs.rutgers.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Mar 2007, Aniruddha Bohra wrote: > In two drivers, fxp and em, the assumptions about entering the ether_input > routine are different. From em_rxeof: > > #ifdef DEVICE_POLLING > EM_UNLOCK() > (*ifp->if_input)() > EM_UNLOCK() > #else > (*ifp->if_input)() > #endif > > While in fxp: > > FXP_UNLOCK() > (*ifp->if_input)() > FXP_LOCK() > > 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. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070316141836.J60288>