Is GLDv3/nemo conversion of legacy drivers worthwhile

That very question, specifically with regard to hme and qfe, but also some others, has come up lately. I'm of one mind (I think my position is clear by the very fact that I've invested effort here), but not everyone shares my opinion.

In order to have an on-line concrete resource I can point internal Sun naysayers at, I'm asking you to voice your thoughts here, by posting a follow up to this blog. (Sorry, no anonymous posts, but that means your posts will carry all that much more weight.)

Do you still use hme/qfe in systems? What about Sun Trunking with qfe? Would you upgrade to Nevada if there was GLDv3 support for these NICs? Would Nemo features in qfe/hme help you? Would a port of hme/qfe to x86 be useful to you?

Please post a follow up on my blog here, with your opinions!

Comments

Nicholas Riley said…
Do you still use hme/qfe in systems?

Yes, about half of our servers use hme/qfe and in fact we just installed two qfe cards in machines last week to use with our new Sun Cluster setup. We have plenty of such older servers in use and no real plans to get rid of them, as they perform adequately.

What about Sun Trunking with qfe? Would you upgrade to Nevada if there was GLDv3 support for these NICs? Would Nemo features in qfe/hme help you?

The most important Solaris networking feature we wish we had right now is part of Crossbow, specifically zone exclusive IP stacks. We're using zones extensively on our machines that still have hme/qfe in them. And as that requires a Nemo-supported interface, absolutely. I don't see we'd use trunking much with 100Mbit Ethernet because if performance mattered that much we'd just use a single gigabit interface.

Would a port of hme/qfe to x86 be useful to you?

No, we don't use hme/qfe on x86 and don't have any plan to (the new x86 servers we're getting already have enough Ethernet ports).

Hope this helps... I've really been enjoying following your blog and learning more about GLDv3 and so forth.
June 3, 2007 at 12:37 AM
Andjo said…
Do you still use hme/qfe in systems?

Hme, yes. We tend to recycle older machines and turn them into special purpose servers.

Would Nemo features in qfe/hme help you?

Multiple VLAN support would be beneficial in several cases. Instead of Solaris/SPARC we have deployed Linux/x86 a few times for that reason.

Would a port of hme/qfe to x86 be useful to you?

Not at work, but it would make a qfe card I have at home more useful to me.
June 4, 2007 at 6:02 AM
Anonymous said…
My organization (a large US research university) still has many "legacy" servers with hme (and eri for that matter). For that matter, we also have servers with ce, which I would love to see converted to nemo.

In my group, we have a v490 (with several ce interfaces) running multiple zones. Several users want IP instances, so I'm going to have to migrate some of the zones to a v240. We're running Sun Trunking on the 490, and I would love to ditch it in favor of nemo's native 802.3ad support.

An x86 port of hme/qfe wouldn't be that useful to us.
June 4, 2007 at 7:26 AM
Unknown said…
About ce, I can tell you that I definitely plan on doing a Nemo port of it, if nobody else beats me to the punch. These earlier, 10/100 devices, I'm doing first, mostly because they are easier, and less likely to be viewed controversially by the folks that own the code. ce is a very big driver (about 20,000 lines of code!), and it desperately needs some of the love that I intend to give it.

Additionally, ce hardware has some features which complicate a port, but ultimately make it a very nice device for nemo. This includes a hardware classifier, multiple send/receive rings with separate interrupts, and the ability to do TCP segmentation offload.

So watch this space for news about ce in the future.

And, thanks to the folks that have posted here. I'm now beginning to question the merit of doing the work to convert port hme/qfe to Solaris x86, but I will definitely drive forward with the hme port to GLDv3. qfe is "interesting" because of Sun Trunking, but I'll endeavor to figure out a nice solution for it, as well.
June 4, 2007 at 9:22 AM
Unknown said…
Is there anywhere to get status on work being done with hme, qfe, and especially ce drivers for nemo? We have very specific requirements that require the aggr interfaces on servers that only support ce cards.

Thanks!
December 12, 2007 at 7:41 AM
Unknown said…
HME and QFE are done. They have been in Nevada for a while now. Enjoy!

This next bit is just my opinion, and doesn't represent anything official from Sun ... as with the rest of this blog, this is entirely not part of my "day" job at Sun.

CE is entirely a different matter. I have the code mostly done, but I can guarantee you it will never see the light of day.

Why? Because of entirely non-technical reasons. The group that "owns" ce has no interest in seeing a GLDv3 ce driver, and I have not been able to generate sufficient interest.

If any of my readers feel that this is a very unhappy situation, they are welcome to contact their Sun reps (if anyone knows Jonathan or Jeff Jackson, and is unhappy about the situation, they can contact them!) Go ahead and use my name! I'd be quite happy to explain the situation, and offer assistance, if someone senior enough to override the NSN management gets involved. But at the moment, the NSN management (all the way up to the highest levels, from what I can see) is uninterested in such an effort, even if it were handed to them, on the basis of increased support costs and detracting resources from other projects they may be working on.

It will take some customer with significant revenue to push hard enough to get an Exec. VP or higher involved to change the picture, I think. (Which doesn't mean it can't be done, just that the case is going to have to be pushed hard.)

One band-aid that is coming out is support for ce with IP exclusive zones. This is not a full GLDv3 port though, and it won't do anything for aggr.

If you're running on S10, you could also look at the Sun Trunking product. I think it probably costs extra though, and it isn't supported on Nevada.
December 13, 2007 at 12:35 PM
Post a Comment

Popular posts from this blog

An important milestone

Yesterday, with very little fanfare, illumos passed an important milestone. This milestone was the integration of  195 Need replacement for nfs/lockd+klm This is work that I originally tasked Gordon Ross and Dan Kruchinin to work while we were colleagues at  Nexenta .  Gordon started the work, picking up bits from FreeBSD as a starting point and gluing it to the illumos entry points.  Dan continued with it, and fleshed out a lot of the skeleton that Gordon had started.  It was subsequently picked up by the engineers at Delphix , and -- after some important bug fixing work was completed -- was integrated into their product quite some time ago -- reportedly its been stable since December in their product. The reason this is such an important milestone, is two fold: First, this represents a substantial collaborative effort, involving contributions from parties across several organizational boundaries.  The level of collaboration achieved here is a w...
Read more

GNU grep - A Cautionary Tale About GPLv3

My company, DEY Storage Systems , is in the process of creating a new product around the illumos operating system.  As you might imagine, this product includes a variety of open and proprietary source code.  The product itself is not delivered as a separate executable, but as a complete product.  We don't permit our customers to crack it open, both from the sense of protecting our IP, but also to protect our support and release engineering organizations -- our software releases consist only of a single file and we don't supply tools or source for other parties to modify that file. One of the pieces that we wanted to integrate into the tree is an excellent little piece of software called Zookeeper , produced by the Apache organization.  Like illumos, Zookeeper has a nice non-viral copyleft license, which makes it nice for integration into our product. However, I discovered that as part of our integration, one of my engineers had decided to integrate GNU grep. ...
Read more

The Hand May Be Forced

Well, as you may have read , Oracle has decided that at some point very soon, we're going to lose normal regular access to the source code for OS/Net. (I.e. the Solaris kernel and supporting programs.) While I would have vastly preferred for Illumos to have a cooperative and collaborative relationship with Oracle , it appears that Oracle doesn't value this. In fact, the exact words were from the management at Oracle were as follows: Solaris is not something we outsource to others, it is not the assembly of someone else’s technology, and it is not a sustaining-only product. While I understand the need to own the technology, there are few things that could be stated that show a stronger NIH attitude than this. Its unlikely that there will ever be a way for Oracle and the greater community to have a collaborative relationship. This is a dark day for OpenSolaris -- its effectively dead now. (Its parent, Solaris, lives on however.) How unfortunate. For Oracle that is. Because...
Read more