[openib-general] CMA issue: SDP login compliancy

Michael Krause krause at cup.hp.com
Mon Dec 4 11:32:22 PST 2006


At 09:14 AM 12/4/2006, Steve Wise wrote:
>On Mon, 2006-12-04 at 18:57 +0200, Michael S. Tsirkin wrote:
> > > Subject: CMA issue: SDP login compliancy
> > >
> > > Hi!
> > > SDP compliance statement *requires* that a consumer checks the
> > > Responder Resources field in the connection Request/Response,
> > > verifying that it is > 0. This is part of CA 4-41 in the spec.
> > >
> > > However Responder Resources field does not seem to be exposed by the 
> CMA API.  I
> > > think knowing this value (at least in REQ, but preferably in REP is 
> well) is
> > > also important for any ULP that does RDMA reads.
> > >
> > > Should/can CMA/UCMA be extended to pass this to the user? This might be
> > > something we need to address before UCMA merge to avoid ABI breakage 
> later.
> >
> > Steve, could you please comment on the iWarp side of things?
> > Does iwarp connection get the number of RDMA read requests remote side
> > can support during connection setup?
> > Or is this IB-specific?
> >
>
>I believe Sean's latest CMA patches under consideration for 2.6.20
>support this from a CMA perspective.
>
>See http://thread.gmane.org/gmane.linux.drivers.openib/33576/focus=33580
>
>iWARP (MPA protocol) currently doesn't exchange this information across
>the wire at connection setup, but there are proposals in the works to
>support this (It requires a wire protocol change).  So eventually, iWARP
>will provide the remote peer's responder resources in the connection
>events.

SDP Hello exchanges the number of SrcAvail for each side of the 
communication in addition to other resource information - this provides the 
RDMA Read Request depth information.  I am not aware of any request to 
modify MPA which just completed last call in November.  The same type of 
information is exchanged during iSCSI login.  The consensus was since each 
ULP exchanges this information during their initial ULP-level 
communication, there was no reason to replicate this within MPA.

Mike 






More information about the general mailing list