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

Hal Rosenstock halr at voltaire.com
Fri Feb 17 07:16:00 PST 2006


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.

-- Hal




More information about the general mailing list