[openib-general] Re: Re: Re: [PATCH] change Mellanox SDP workaround toa moduleparameter

[Michael S. Tsirkin]

Quoting r. Hal Rosenstock <halr at voltaire.com>:
> Subject: RE: Re: Re: [PATCH] change Mellanox SDP workaround toa moduleparameter
> 
> On Thu, 2006-02-16 at 14:53, Dror Goldenberg wrote:
> > > From: openib-general-bounces at openib.org 
> > > [mailto:openib-general-bounces at openib.org] 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 <halr at voltaire.com>:
> > > > > 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