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

List:       opensolaris-driver-discuss
Subject:    [driver-discuss] NIC futures.... cassini, GLDv3, legacy, etc.
From:       "Garrett D'Amore" <Garrett.Damore () Sun ! COM>
Date:       2007-06-09 6:05:02
Message-ID: 466A430E.9000207 () sun ! com
[Download RAW message or body]

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

_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
[prev in list] [next in list] [prev in thread] [next in thread]