[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-code
Subject:    [osol-code] Re: [driver-discuss] GLDv3 (or v4) enhancements...
From:       "Garrett D'Amore" <garrett_damore () tadpole ! com>
Date:       2006-11-22 17:33:42
Message-ID: 456489F6.3020301 () tadpole ! com
[Download RAW message or body]

Paul Durrant wrote:
> cc-ing reply to network-discuss since that's where most of the Nemo
> (GLDv3 - I wish it was never called that, it's too confusing) folks
> hang out...
>
> On 11/22/06, Garrett D'Amore <garrett_damore@tadpole.com> wrote:
>> 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.
>>
>
> With v3 a.k.a. Nemo, the mac layer processing is divorced from STREAMS
> by the data-link services module (dls). This is a functional
> interface, which I did at one point code up with the possibility of
> handling async. completion but it just got too messy, and none of the
> existing drivers were using it, so I pulled it out.

There are existing drivers that could certainly make use of it.  I know
of at least a couple, including the PRISM driver (both Sun's and
Tadpole's), and my own "mxfe" driver for Macronix based tulip clones.  I
suspect Masa-san has a bit of experience with others.  Right now these
all drv_usecwait(), and in the case of the prism code, its particularly
nasty.

Basically, the "messiness" gets moved from GLD into the drivers in this
case, and the drivers have to make some unfortunate sacrifices because
GLD drivers don't have access to the streams themselves, so they can't,
for example, defer execution or send a reply directly upstream.

> Do you know of any current or forthcoming h/w that would require the
> ability to asynchronously complete operations?

I'm not sure if dmfe uses the old tulip style of "sending" a custom
frame to set the multicast filter.  I know that some tulip clones do
this and some don't.  The ADMtek variants do not (thankfully).  I think
Davicom and ADMtek (now Infineon) may be the only chip vendors still
producing tulip variants (apart from certain SoC vendors, e.g. Atheros
has a tulip-clone in their embedded WiSoC.)

I would actually expect that some newer parts would use this type of
configuration _more_, as the number of items to configure, and resulting
complexity, increases.  That said, I've not looked seriously at many of
the more modern chips to say for certain.

I also expect this is a major problem for a great many of the USB-based
NICs out there, because USB is by its very nature asynchronous.  Maybe
Masa can say more.  (At one point I looked at writing a driver for the
ASIX USB ethernet, and I certainly ran into these kinds of issues.)

>
>> 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.
>
> gldm_send() is not a v3 entry point. All v3 drivers are coded to the
> 'mac' interface - see usr/src/uts/common/sys/mac.h

Right.  I meant that for gldv3 there may be entry points other than send.

    -- Garrett

-- 
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
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
[prev in list] [next in list] [prev in thread] [next in thread]