At 10:59 AM 3/10/2006, Bryan O'Sullivan wrote: >On Fri, 2006-03-10 at 09:06 -0500, Talpey, Thomas wrote: > >> This strikes me as very unwise. In addition to duplicating a standardized >> IPoIB facility, is the emulation supported by any other implementation? > >No, it's specific to our hardware. Its main purpose is to provide an IP >stack that works over the fabric when there are no IB drivers present, >so it's not duplicating IPoIB in any meaningful sense.
This is not sufficient justification to introduce an incompatible and redundant Ethernet emulation layer into the core. Will it work in a system where IPoIB is enabled? How do you handle IP addressing and discovery? Have you tested it under all upper layers including IPv6? What apps do your users run? >> Who will be using this code *without* having enabled the current OpenIB >> support? > >We already have a pile of customers using it. It happens to have lower >latency and higher bandwidth than IPoIB, but I suspect that's in part >because we haven't had time to tune IPoIB yet. You need to put your effort into supporting IPoIB. I would like to know what "tuning it" means btw. >> What standardization is planned for this new protocol? > >None at present. It's there for people who want it, and people are >already using it. For those who need something standards-based, there's >IPoIB. That just doesn't cut it. "Standard is better than Better." This code is at the moment a proprietary extension, being proposed for global inclusion. At a minimum, you need to document its protocol, and quantify its performance advantages. If so, perhaps it can be justified as an experimental upper layer. By the way, what's the name of this component? Tom. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
