> > It doesn't really matter how much closer we get unless we can deal with > > the third-party driver problem (and some third parties won't even consider > > a GLDv3 conversion until they don't have to support S8/S9). > > How many 3rd party drivers are using some of the ugly internals like > DL_CAPABILITY_REQ (which is not a public interface), or DL_CONTROL_REQ, > for example?
DL_CONTROL_REQ is an internal IPsec thing that is tied to Venus, which AFAIK is not open-source (and is already EOL'd) -- so it seems independent of this porting effort. DL_CAPABILITY_REQ is more of a question mark. > What about DL_IOC_HDR_INFO? All third-party drivers that I know of use DL_IOC_HDR_INFO. > Or DLIOCNATIVE? No drivers implement DLIOCNATIVE -- it's handled exclusively inside GLDv3 and it will stay that way. That said, it's documented in dlpi(7P) for use by applications like WireShark (and in fact, I have a patch to submit to the WireShark guys that turns it on). > These Sun-private DLPI extensions can simply go away if all the > consumers of them go away. For some of these cases, we have 100% > control over that at Sun. See above -- even if you ported all of the open-sourced drivers to GLDv3, you'd still be left with these interfaces. > Does this mean that Clearview is going to know about all the special > case stats that each of these drivers exports? (I.e. is there going to > be a switch table entry in Clearview for hme, qfe, gem, etc.?) IIRC, softmac knows about the common names for kstats, and may try more than one when interacting with an underlying driver. It doesn't know one-offs for various drivers. We are not trying to handle the ndd case -- that's Brussels territory. > The NDD driver ioctl interfaces have never been published, and aren't > part of the DDI. I hope there aren't 3rd party drivers that are relying > on that particular interface. There are -- e.g., Syskonnect's drivers support them. > The point is, if its a Sun-internal-only interface, then it should be > possible for us to fix it. It leaked out a long time ago. > The only way Clearview can do multiaddress mode is by putting the > interface in promiscuous mode. This causes all kinds of performance > penalty in the underlying drivers. (From the fact that the underlying > drivers perform an extra "dupmsg" to the fact that you take and process > _every_ packet on the wire.) I sincerely hope you're not suggesting > that this is equivalent to having the native ability in the driver to > put multiple unicast addresses in the device's mac address hardware filter. I was speaking more generally of Crossbow features. Yes, some things may not be tenable, though IIRC Crossbow already reverts to promiscuous mode when more addresses are needed than the hardware can directly support. > This doesn't get you multidata transmit and receive _at the driver > level_. It just makes the stack think that you're getting it. Sure, > its better than nothing, but its also not as good as having that all the > way down at the driver level. (E.g. the driver isn't doing multiple > putnext() calls, or multiple gld_recv() calls. Likewise for tx...) First, my recollection is that GLDv3 does not support MDT -- only LSO. Further, as I recall, the plan was to remove MDT support and use LSO consistently. So I'm not sure this is much of a concern. > > > 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.) > > > > That seems orthogonal to the GLDv3 work. GLDv3 does not specify the > > loopback testing model AFAIK. > > Its coming with brussels, I think. That may mean its only available to > GLDv3 drivers. I don't think so. It should be easy for any driver to support those ioctls. I'd welcome adding some common utility routines in the kernel to make that easy. > > > 10) making these drivers DLPI style 1, bringing us much closer to > > > removing the long standing DLPI style 2 "bug". > > > > Again, this is part of Clearview UV. All drivers will have DLPI style 1 > > nodes in /dev/net. No porting necessary. > > Fair enough. But will there also be /dev/hme nodes? Will clearview > make tools like snoop automatically use the style 1 nodes? Yes. All DLPI applications in ON will use libdlpi (in fact, a few already do, including snoop), which will look in /dev/net before /dev. We have also made the libdlpi API available for third-party use (there are complete manpages), though we recognize that it may take some time for things to be ported to use it. (BTW, libdlpi rips out tons of code :-) > Will there be a /dev/net/hme0 if I have not set up a vanity name? Yes, that will be the default name. > But, by moving such large amounts of code to the GLDv3, you actually > greatly simplify the drivers thereby making support much, much easier > for them. Ultimately this reduces long term headaches, unless you're > going to propose that the existing drivers are flawless and will never > need to be touched again. Of course they're not flawless -- and this is a good argument, but to me it's more an argument for getting GLDv3 out the door than it is for rewriting the past. -- meem _______________________________________________ networking-discuss mailing list [email protected]
