<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

  <title></title>

</head>

<body bgcolor="#ffffff" text="#000000">

<br>

<br>

Sean Hefty wrote:

<blockquote cite="mid:000301c84e6d$c0904020$ff0da8c0@amr.corp.intel.com"

 type="cite">

  <blockquote type="cite">

    <pre wrap="">What exactly are you fixing?

    </pre>

  </blockquote>

  <pre wrap=""><!---->

It may help to look at the patch for the librdmacm that I just posted.  The

problem that was seen was that uDAPL set IRD/ORD to 16 in the connection

request, but the passive side could only support 4.  The rdma_cm was supposed to

use the lower value (provided by the user when calling rdma_accept) when

transitioning the QP, but instead used the value from the request.

Since iWarp connect request doesn't carry the IRD/ORD and always uses the value

provided by the user through rdma_connect or rdma_accept, it doesn't sound like

it would hit this problem.  I just don't quite follow why

iwcm_init_qp_rts_attr() doesn't set the QP attribute mask for IRD/ORD, or how

the QP is programmed with these values.

  </pre>

</blockquote>

Perhaps this is a bug.  But the chelsio driver just saves off the

ord/ird from the connection parameters and then programs the qp with

these values when the qp is associated with the connection (just after

the connection goes into rdma mode)...<br>

<br>

<blockquote cite="mid:000301c84e6d$c0904020$ff0da8c0@amr.corp.intel.com"

 type="cite">

  <pre wrap="">- Sean

  </pre>

</blockquote>

<br>

<br>

</body>

</html>