I've run into, in the past, chips (prism and tulip are good examples)
for which functions like setting a multicast address, configuring a wep
key, or various other functions, are not "immediate".  That is, these
commands can sometimes take a little while for the chip to process, and
the completion is often signaled by an interrupt.  This leads to drivers
doing drv_usecwait(), when they really could be using cv_wait if GLD
were more cooperative.

In GLDv2 (and also v3, I believe), it is not good form to cv_wait for an
interrupt to complete, because these entry points might be called from
srv(9e) running on a (possibly unrelated) interrupt.

I would like to see an option in GLD for the driver to indicate that it
wants to be able to sleep in these entry points.   This could be done
with a flag in the mac_info structure or somesuch.  (Most of these
commans are called infrequently enough that it probably would not be
unreasonable for GLD to _always_ permit sleeping.)

GLD  could achieve this by having the original DLPI message (e.g.
DL_PROMISCON_REQ or DL_SET_PHYS_ADDR_REQ, or DL_GET_STATISTICS_REQ)
spawn a task (on a taskq) to call the entry point.  This task would also
be responsible for sending the reply message back upstream.

The benefit is that all GLD entry points (except of course, 
gldm_send(9e)) (and possibly other GLDv3 entry points) would be free
from restrictions related to interrupt handling.  This could simplify
the life of folks who have to write these kinds of drivers (for devices
that need a tiny bit more time to complete certain kinds of
configuration changes), while possibly improving overall performance
(because some of these can sleep instead of spinning for milliseconds at
a time.)

The ultimate code changes to do this would not be too great, though it
would involve a taskq and some basic synchronization against races with
close(9e), but even that does not seem like it would be too much of a
challenge.

Thoughts?

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191

_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to