[ofa-general] mthca wc->opcode for CQEs with error status

[Roland Dreier]

 > 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.