I've gone ahead and done a conversion of dmfe to GLDv3 (nemo). I
actually have a dmfe device on SPARC (in this case its on a SPARC
laptop), so I figured this would be beneficial.
I'd like to have folks review the work at
http://cr.grommit.com/~gdamore/dmfe_gldv3/webrev
A few quick notes:
* I nixed the redundant "mii" kstats... nemo already tracks them.
* This will make dmfe a DLPI style 1 provider as well. (A good
thing, IMO, DLPI style 2 is a "bug".)
* A few kstats got "lost" since Nemo doesn't support them... the
remfault kstats, the runt packets kstat, and maybe one or two others.
* DMFE doesn't support multiple rings, so I didn't bother with
"mac_resource_add". However, it could in theory support polling, but
since it appears that the polling framework for crossbow isn't
integrated yet, I didn't add it. (Its unclear whether its worth doing
this for a 100Mbps device anyway.)
* DMFE could easily support multiple unicast addresses. If there is
value in this, I can go back and add the necessary bits to support it.
(I'm thinking this could be useful for VNICs.)
* I'd love to replace the dmfe-custom loopback ioctls with standards
sys/netlb.h ioctls. However, I'm not sure if any consumers are going to
be impacted.
* As a result of other kstat related changes, its possible that the
interpretation of certain values might not be identical, e.g.
link_duplex, etc. (But as a bonus, dladm show-dev now properly reports
link information!)
I'm thinking that I'll probably run this by ARC as a self-approved
fasttrack. Ideas?
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
