Masayuki Murayama wrote:
7) enabling legacy:
a) hme (and qfe) and certain modern variants of
iprb can do IP
hecksum offload, but it was never enabled by the
drivers. If someone
wants to take a crack at it after my GLDv3, its a
small driver task. A
good community project. Let me know .
b) eri, ce, and gem can all do dynamic interrupt
blanking. So can
thers (iprb, and dmfe as well, I think.) We could
activate this in the
drivers. Again, not a big project. Let me know if
you want to help.
c) We could also provide polling interfaces for
crossbow, when that
comes into Nevada. Only the gigE drivers are likely
to get attention
here. If you're interesting in helping out with
other legacy drivers,
let me know.
d) multi-address support. Useful for VNICs and
crossbow. Again,
legacy NICs are likely not to get attention from
Sun... unless someone
else steps up to the plate.
e) ndd/kstat cleanup. Brussels is going to do
some work here, but I
hink there is an opportunity for others to pitch in.
Some drivers need
dd tuning support for link, consistency changes, etc.
f) more legacy driver conversions. E.g. dnet
could be updated to
LDv3, etc. There's a bunch of closed ones, too.
I recommend to make a new common layer for managing tx/rx
buffers, tx/rx descriptor rings, and MII link. In my experience
on writing various nic drivers, they were common.
Actually I tried to make such a common layer, and it reduced
the lines in hardware depend section. Typically it was 1500 - 2500
lines for a driver.
Right. See my earlier reply to this. I want to do exactly this as part
of a Nemo 2 project. I've asked around, but I don't seem to have
triggered management's interest yet. (I'd like to be the lead on just
this project. And there are other features I'd like to see from Nemo 2,
as well. For example, interrupt accounting could be used to help drive
the decision to switch between polling and interrupting modes ... right
now the framework has no way of knowing how long a driver is spending in
interrupt context receiving multiple packets.)
8) Open sourcing. Cassini and a number of x86 nics
are currently
closed. I'd like to get this changed. I think some
of this was
deprioritized into the bit bucket, but conceivably a
few of them should
be doable without too much legal arm wrestling (iprb,
cassini -- Sun
owns all ce's IP, maybe others.) At some level, I
hope my GLDv3 efforts
will help because it means that the amount of
material that has to be
subject to a legal review will be much, much smaller.
I think all device drivers must be opensource when opensolaris
become *real* open source operating system.
Closed source drivers will prevent opensoalris from porting it
on another archetecture, including powerpc, mips.
Maybe, maybe not. That's a different philosophical debate. Certainly
for the drivers for add-in cards, it would be _nice_ to have them be
open source. I really want to see cassini go opensource, but right now
it needs a lot of attention first. I'm working on that in my spare
time, and quite frankly, without approval from the folks who own the
cassini code. I may or may not be able to get approval to release any
of my efforts here back to the community --- regardless of whether as
open or closed source.
9) Porting. Some of the drivers are conceivably
useful on more than one
architecture, but are only enabled on that one. dmfe
is a good
example. dnet is another. (dnet would be very
useful on sparc, and
amd64 platforms, because there are some quad-port
cards that have real
21143 tulip parts on them.)
I think dnet must be enhanced for 21143 chipset.
It doesn't work for my 21143 based network cards. According
my experience on making 2114x driver, dnet doesn't seem to
implement autonegotiation capability on 21143 SYN interfaces.
Actually, dnet is really, really crufty. I wouldn't mind just wholesale
replacing it with another driver. (Your "tu" might be a suitable
replacement.... However, I'd prefer not to have "tu" replace some of the
other drivers that are out there .... my own afe and mxfe drivers, and
the dmfe driver are examples.)
The funny thing is that real 21143's have not been sold for many many
years now. I sort of just hope that we can just let the driver die a
quiet death. But those few quad-port 21143 cards are the one
problematic part.
(If such a card "appeared" on my doorstep, I might be convinced to
update dnet to work with it... including GLDv3. But now I have
approximately zero reason to work on it.)
-- Garrett
-masa
This message posted from opensolaris.org
_______________________________________________
networking-discuss mailing list
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
