> I don't understand why you are taking such a non-cooperative posture for > a simple request. All hardware models support this capability and it's > a 1 line change for mthca to parallel the other drivers. > > Most previous stacks, including VAPI, had this capability. > > While I agree applications should be coded strictly to the spec, that > has not stopped us from putting non-standard features into OFED, so why > now? FMR is just one such example.
If this were some feature that allowed us to do something new, or made applications more efficient, or something like that, I'd be all for it, specs be damned. But in this case it's just bloating driver code to work around buggy applications. And I'd rather use my I$ for something more useful. (And in fact the proposed change is itself buggy -- it calls any completion on the send queue a send, even if it was actually something else like RDMA read/write, atomic, etc) > In a quick review of existing OFED 1.2 code, there are a number of > places where debug and diagnostic messages output status and opcode, > ipoib_ib.c is one such place. Having such messages indicate at least > the direction of the failed transfer can be invaluable to debug. Actually the ipoib example at least is a place where printing the opcode is just pointless -- the message already says whether it's a send or a receive, and the opcode field is at best redundant. I'll queue a patch for 2.6.22 to clean that up. Are there any other places where the consumer doesn't already know whether the failed completion came from the send queue or the receive queue? - R. _______________________________________________ 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
