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

[Michael S. Tsirkin]

Quoting r. Hal Rosenstock <halr at voltaire.com>:
> > > >     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.

No idea. Possibly the REJ code 26 was deemed sufficient.
We'll need some kind of solution before we start creating SDP clients
with different max mtu values, controlled from software.

-- 
Michael S. Tsirkin
Staff Engineer, Mellanox Technologies