Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > Subject: RE: Re: Re: [PATCH] change Mellanox SDP workaround toa > moduleparameter > > On Thu, 2006-02-16 at 14:53, Dror Goldenberg wrote: > > > 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 :) > > Thanks for the historical perspective. It's harder to overturn an > existing vote on something at the IBTA. Not sure I have the time to take > up this (larger) mission.
Assuming the spec says as it is, then: 1. CMA needs to be modified to retry the connection if its rejected because of lower MTU. 2. SDP/SRP protocols specs need a clarification: e.g. current SDP spec says the connection should be closed when we get a REJ. -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
