It is indeed good that you check for performance degradation. However, when a
__single__ BTL requires changes that affects all BTL/PML, you cannot just
assume an RFC is not necessary. This change affects all RDMA headers for all
BTL / PML, it is indeed a critical change even if it is not on the
Thats the nice thing about this change. Segments are only sent for larger
messages which is where we will need the extra bits.
And, you can blame Cray for their 128 bit memory registration key.
-Nathan
On Mon, 7 Nov 2011 09:22:58 -0500, Jeff Squyres wrote:
> This is probably why it would have b
This is probably why it would have been good to RFC about this. :-)
8 bytes can/does affect short message latency, no?
On Nov 6, 2011, at 11:29 PM, Nathan T. Hjelm wrote:
> I saw no need for an rfc for r25445/r25448. I did not seen any performance
> degradation with openib, sm, or vader (usin
I saw no need for an rfc for r25445/r25448. I did not seen any performance
degradation with openib, sm, or vader (using ob1). Its only 8 bytes, and we
(LANL) will absolutely require a 128 bit key for the ugni btl.
Anyone else care to weigh in or do some measurements?
-Nathan
On Sun, 6 Nov 2011
I might have missed some of the phone conferences, but this is a highly
critical modification of the one of the performance critical sub-system of Open
MPI. There was no RFC about and no prior warning. This change impacts every
other BTL and PML out there. Moreover, at this point there is no ass
