On Thu, 2006-02-16 at 02:54, Michael S. Tsirkin wrote: > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > Subject: Re: Re: [PATCH] change Mellanox SDP workaround to a moduleparameter > > > > On Wed, 2006-02-15 at 19:03, Roland Dreier wrote: > > > mst> I thought about it some more: what happens if nodes with > > > mst> different max MTU values try to connect? > > > > > > This should never happen. The SM should never give a path with an MTU > > > that is not supported by both end nodes. > > > > True, but the description for the CM REJ code 26 for Invalid Path MTU > > states something a little different (p. 667): > > > > "The recepient of the REQ message cannot support the maximum packet > > payload size requested." > > Right. > > > is being interpreted as "prefers not to support the max payload size > > requested" which is probably OK. > > > > > I guess the question is what to do when a Tavor (with the performance > > > bug that makes a 1K MTU faster) connects to someone else. > > > > Isn't it the other way 'round (when something with a larger MTU connects > > to Tavor) ? > > Right. I wish we had an MTU field in the REP packet, but we dont.
Yes, that would be better IMO too. Not sure why it wasn't done that way. Guess you could file an erratum on this. -- Hal _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
