> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Hal Rosenstock > Sent: Thursday, February 16, 2006 1:13 PM > > 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: > > > > > > > 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
The SWG defined a generic mechanism which uses REJ to indicate that the passive side does not accept a certain REQ fields, and allows the passive side to indicate an alternative value. Indirection is also supported through the same protocol. It also allows the active side, following the REJ, to use an alternate value, other than the one suggested by the passive side, i.e. passive side only has a veto capability. This is the mechanism and the short theory behind it. Unfortunately it's a bit inefficient in terms of performance because of the ping pong of messages. Solving just the MTU might not be a good enough argument. The approach should be to enable the active side to specify a set of acceptable parameters for each one of the REQ fields, and then let the passive side to choose. This may change the CM packets all over and will introduce new problems. I don't think that there's a good chance of just adding a solution for just one of the fields. Anyway, you can still try and propose this to IBTA, I tried it once already :) _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
