Nicolas Droux wrote:
On Apr 18, 2007, at 11:38 AM, Garrett D'Amore wrote:
Heavily used depends on what systems you have at hand. hme and eri
are _widely_ deployed, and _widely_ used. E.g. all UltraSPARC
II/IIi/IIe based systems shipped with either eri or hme. This
includes "big" systems like E10k, E6500, etc.
The other "popular" nic is qfe, but that code doesn't live in ON
where I can readily access it. (The argument for doing qfe is
probably quite compelling, as a lot of qfe NICs were sold, even well
after gigabit started to become popular.)
We can probably compile a long list of drivers which are commonly used
on the various platforms that have shipped over the years. The vast
majority of these drivers are however not even 1Gb/s NICs, and should
work fine under the Nemo unification softmac shim, which will bring
them under the Nemo framework without porting needed.
Here are the compelling reasons to consider moving some of these legacy
drivers to Nemo:
1) these drivers have a lot of cut-n-paste code... e.g. DLPI
handling in hme, eri, probably contribute over 5K lines _each_. Most of
that code is also duplicated in both GLDv2 and in nemo. More lines of
code == more chances for bugs == more support headaches.
2) nemo-ification automatically gets quite a bit of "free"
performance in fewer CPU cycles used (direct function calls, etc.)
3) it gets us one step closer to being able to eliminate legacy
APIs... possibly making the _frameworks_ simpler. (For example, some
Consolidation Private and Contracted Private interfaces for things like
HW checksum offload, DLPI fastpath, etc. can pretty much get eradicated
once the last Sun consumers of them go away.)
4) centralizing functionality for stuff like DLPI handling means
reduces long term support costs for drivers like eri, hme, etc.
5) unifies administrative tasks... e.g. these drivers can adopt
things like Brussels, will "just work" with dladm (they don't today!) etc.
6) ultimately leading us one step closer towards nixing "ndd" (see
point #3 above, again) (Also removing duplicated kstat and ndd code in
_these_ drivers.)
7) paves the way for these drivers to support additional crossbow
features like Multiple Unicast Address support, interrupt blanking
(which may or may not be useful with 100Mb links... but imagine an older
system like an E450 with a few dozen 100Mbit links on it...)
8) as another item on #2, nemoification gets free
multi-data-transmit (and receive!), yielding better performance as well.
9) ultimately, also eradicating special case code in places like
SunVTS and other test suites, that have special cases for devices like
hme, gem, etc. (e.g. using custom ioctls to set loopback modes.)
10) making these drivers DLPI style 1, bringing us much closer to
removing the long standing DLPI style 2 "bug".
Finally, for most of these legacy drivers, the effort to convert is
quite small. On the order of a man day. Seriously. With all these
benefits at such a low cost, why _wouldn't_ we do it?
Historically the complaint was that GLDv2 wouldn't support everything
these drivers wanted, or couldn't keep up in terms of performance (that
was an outright lie, as my analysis some 4 years ago showed). With
nemo, this is the way to go.
-- Garrett
Nicolas.
--Nicolas Droux - Solaris Networking - Sun Microsystems, Inc.
[EMAIL PROTECTED] - http://blogs.sun.com/droux
_______________________________________________
crossbow-discuss mailing list
[EMAIL PROTECTED]
http://opensolaris.org/mailman/listinfo/crossbow-discuss
_______________________________________________
networking-discuss mailing list
[email protected]
