Date: Fri, 4 Mar 2005 01:42:26 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: net@FreeBSD.org Subject: Re: Giant-free polling [PATCH] Message-ID: <Pine.NEB.3.96L.1050304014102.90055A-100000@fledge.watson.org> In-Reply-To: <20050303232458.GO9291@darkness.comp.waw.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 4 Mar 2005, Pawel Jakub Dawidek wrote: > On Tue, Mar 01, 2005 at 04:29:49PM -0800, Luigi Rizzo wrote: > +> [cc-ing net@freebsd.org to get more opinions] > +> > +> On Tue, Mar 01, 2005 at 04:42:48PM -0500, John Baldwin wrote: > +> > On Thursday 17 February 2005 07:10 pm, Luigi Rizzo wrote: > +> > > i am no expert about the locking but i see places where > +> > > you grab polling_lock followed by ifnet_lock, and others where > +> > > you use the opposite order. This seems prone to deadlock... > +> > > +> > Yes, it basically seems that the polling_lock should be removed and just the > +> > ifnet_lock used because the the ifnet_lock is already always held when the > +> > polling_lock is locked. > > Yeah, but we cannot grap ifnet_lock in polling code, because this is > internal mutex, not visible from outside. I was thinking about moving > ifnet_lock into ifnet structure... One caution here -- while currently the vast majority of our drivers protect per-softc state with a single mutex, in the future this will not be true. Many network cards are implemented with fairly independent receive and transmit units, so it's easy to imagine protecting receive and transmit with separate mutexes so that receive and transmit can occur simultaenously and independently -- for example, for packet bridging or forwarding. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050304014102.90055A-100000>