[openib-general] Re: CMA backlog

[Michael S. Tsirkin]

Quoting r. Fabian Tillier <ftillier at silverstorm.com>:
> Subject: Re: [openib-general] Re: CMA backlog
> 
> On 5/30/06, Michael S. Tsirkin <mst at mellanox.co.il> wrote:
> >Quoting r. Sean Hefty <sean.hefty at intel.com>:
> >> >Currently, this is not something that can be implemented by ULP on top 
> >of
> >> >CMA, because returning error from REQ will result in reject rather than 
> >REQ
> >> >drop.
> >>
> >> A generic ULP could handle this by making use of the private data, and 
> >retrying
> >> requests after a REJ with insufficient resources.
> >
> >You are right in this, of course. What I meant is that dropping REQ
> >can not be implemented by ULPs without extending our CMA and CM.
> >
> >As you point out, retrying on reject might make sense for some
> >ULPs, but happily these can already implement this without extending CMA
> >and CM. So we are set there.
> >
> >I suggest adding an option of dropping REQ, emulating TCP behaviour.
> >This is IMO required for SDP, as I read the spec and from I know about 
> >other
> >SDP implementations.
> 
> You mean a half-reject, where it only rejects locally but doesn't send
> the REJ?  This shouldn't be that hard to do if the local CM supported
> a special reject code that would suppress the REJ MAD being sent.

Yes.

> Alternatively, at least in Windows, the CM will continue to retry REQ
> requests if it receives a REJ with INVALID_SID as the reason (i.e. the
> app is not up yet).

This seems like a weird thing to do.
Connecting to a port where no app listens
with TCP generates an immediate error:

	>telnet localhost 3456
	Trying 127.0.0.1...
	telnet: Unable to connect to remote host: Connection refused
	Exit 1

so why would SDP want to behave differently?

> If the Linux CM could do the same, we could use
> this reject reason to "drop" the REQ.

We could I guess, but I don't think this is spec compliant.
Its probably better to really drop it.

-- 
MST