Giant-free polling [PATCH]

[Robert Watson]

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 at 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