[Fwd: [ofa-general] More responder_resources problems]

[Sean Hefty]

>Well, what if we just made this simpler for the ULP. The kernel, when
>it receives and REQ will modify the values as it swaps them so they do
>not exceed the device maximum. The ULP can then further modify them if
>it wants, but does not have to do anything more than copy them into
>the REP to get correct function. This seems to handle the ULPs I have
>looked at..

I had thought about this, but I'm hesitant to mask the requested values that
were specified by the remote ULP.  (Maybe the ULP can connect on a different
device?)  This does seem like the simplest solution though, and I have to
stretch to think of a ULP that wouldn't like this behavior.

>Just setting the value to maximum in the REQ is not enough without the
>passive side limiting it to the device capabilities. That is where I
>started - it is easy to query to device and get the maximum, but just
>putting those values in the REQ causes one side to try to use more
>responder resources than it has. (initiator depth is 128 and responder
>resources are 4 in my test HCAs here)

I was suggesting that the passive side could also use MAX_RDMA, but that doesn't
remove the requirement that the passive side figure out the correct
responder_resources value in order to transition to RTR.

- Sean