On 10/4/06 1:03 PM, "Sean Hefty" <[EMAIL PROTECTED]> wrote:
> Steve Wise wrote:
>> It would be nice, IMO, for the RDMA CM to handle this under the covers
>> and setup the QP appropriately. Thus the parameters need not be passed
>> to the consumer...
>
> The same parameters are also specified when calling rdma_accept(). I think
> these are the values that are used for the connection. (I need to trace
> through
> the code to be sure.) There's no easy way for the passive side to know what
> was
> requested without exporting the values.
>
> We could drop to the lower of the two values, and let users that really care
> what the values are call ib_query_qp() after the connection has been
> established. This has the disadvantage that you couldn't just reject the
> connection if the values weren't what you needed.
>
Can't the passive side receive the active side's ORD/IRD in the
rdma_cm_event. Is providing the values in the rdma_cm_event what you mean by
'exporting' the values? The passive side could then call either rdma_accept
or rdma_reject based on these values. My assumption is that the typical
behavior, however, would be to limit itself to whatever the active side
requested, or what it was capable of and then return these values in it's
own call to rdma_accept. The service provided by the CM is to marshal and
unmarshal these values from reserved private data into the rdma_cm_event
structure. I would think the limitation is that the active side could
effectively overprovision it's QP if the passive side couldn't honor it's
request.
Am I confused?
> - Sean
>
> ___
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
