[openib-general] [PATCH 0 of 20] [RFC] ipath driver - another round for review

[Talpey, Thomas]

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.