>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 _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
