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

[Michael S. Tsirkin]

Quoting r. Sean Hefty <mshefty at ichips.intel.com>:
> > >The CMA needs some additional work to permit re-using an rdma_cm_id after 
> > >a connection has been rejected, so that the user or CMA can modify the 
> > >MTU before trying to re-establish a connection.
> >
> >Given that the issue only affects some hardware, it would be nice to somehow
> >hide this from ULPs, otherwise it seems unlikely that they will get it right.
> 
> Are you wanting _all_ connections to this hardware to change the MTU?  I 
> can see how this would be useful.  I was assuming that this was an SDP only 
> related issue.

Yes.

> I'm not sure where we want this sort of policy.  I'm reluctant to mask this 
> sort of connection change completely in either the IB CM or CMA.  We may 
> still be able to locate the implementation there, but there should be 
> someway for the user to override the settings.

OK, although I expect most ULPs wont use it.

> Since this is a hardware specific problem, can the driver deal with this?  
> All received MADs are given to the driver before being processed.  Can the 
> driver intercept the REQ, consume it, and issue a REJ?  This might be able 
> to deal with the problem on the receive side.  The sender may also want to 
> adjust the MTU based on local hardware, but I'm not sure where's the best 
> place to handle this.

Very tricky. Just testing some bit in CM or CMA makes much more sense to me.
Lets call it mtu_quirk.
We still have the problem on the send side, so I dont think its worth it.

-- 
Michael S. Tsirkin
Staff Engineer, Mellanox Technologies