I've begun a serious investigation into making Cassini into a GLDv3
driver. There are going to be a few non-trivial concerns with such a
port, and I would like to raise this here, so that interested parties
can contact me.
1) MULTIDATA transmit is going to have to go away, because GLDv3 lacks
support for it. (I hope we can use LSO instead, more later.) I'm very
very much hoping that cassini is the only consumer of the Multidata
transmit interfaces, because I'd like to remove all the various checks
for multidata transmit from the hot code paths in IP. (For example,
hwcksum_retreive, and _assoc. Among many others.) In fact, this impact
upon non-cassini NICs .. such as nxge ... is one of the main reasons
that I decided it was time to get serious about this. (Initially, I
might not even implement LSO ... with b_next chains I can probably get
close to the equivalent multidata transmit functionality.... note that
nxge lacks MULTIDATA support as well!)
2) ce -> GLDv3 will require converting to use the Nemo Link Aggregation
instead of Sun Trunking. Personally I think this is a good thing. I
want to see Sun Trunking EOF. (That requires changes in qfe, and maybe
gem. More in a minute.)
3) the old separate VLAN module will hopefully go away as well, pending
QFE changes.
4) hme. I have hme->GLDv3 sitting in a workspace; I need it
code-reviewed. If you want to review code, let me know.
5) qfe. I want qfe to EOF, and hme to provide the functionality for
qfe. I know driver renames are evil, but I think this is warranted
here. The reason is that the combination of different ndd semantics,
Sun Trunking going away, and other GLDv3 changes really means that IMO,
the driver name change is not that terrible. (All the old scripts are
going to break anyway.)
6) ge. I can convert this to GLDv3 pretty easily, but its pretty low on
my list. Its fiber only, and I don't think as many people have them.
Its pretty much the same as an eri chip, so if people want it, let me know.
7) enabling legacy:
a) hme (and qfe) and certain modern variants of iprb can do IP
checksum 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
others (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
think there is an opportunity for others to pitch in. Some drivers need
ndd tuning support for link, consistency changes, etc.
f) more legacy driver conversions. E.g. dnet could be updated to
GLDv3, etc. There's a bunch of closed ones, too.
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.
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.)
Anyway, I wanted to let some folks know what I'm up to, and extend the
offer/request for others to help out. Some parts can be done without
access to closed source, some parts require you to have SWAN access.
Let me know what you want to help with! :-)
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
