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.
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.
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.
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.
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!
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.

Popular posts from this blog

SP (nanomsg) in Pure Go

An important milestone

GNU grep - A Cautionary Tale About GPLv3