[openib-general] Nitpicking: IB spec 1.2

[Hal Rosenstock]

On Tue, 2005-01-04 at 02:56, Michael S. Tsirkin wrote:
> Hello!
> I was looking at IB spec rev 1.2 and I noted a difference with
> how gen2 behaves.
> 
> 11.4.2 COMPLETION QUEUE OPERATIONS
> 11.4.2.1 POLL FOR COMPLETION
> 
> The following appeared in IB spec rev 1.1 first, actually:
> 
> The number of bytes transferred.
> The number of bytes transferred is returned in Work Completions
> for Receive Work Requests for incoming Sends and
> RDMA Writes with Immediate Data. This does not include the
> length of any immediate data.
> The number of bytes transferred is returned in Work Completions
> for Send Work Requests for RDMA Read and Atomic Operations.
> For the RQ of a UD QP that is not associated with an SRQ or
> for an SRQ that is associated with a UD QP, the number of
> bytes transferred is the payload of the message plus the 40
> bytes reserved for the GRH. For the RQ of a UD QP that is not
> associated with an SRQ or for an SRQ that is associated with
> a UD QP, the 40 bytes is always included, whether or not the
> GRH is present.

OK although changing this makes no difference in behavior as no MAD
consumer and I wouldn't expect them to rely on this field because
as there is no way to indicate whether the GRH is actually
present or not other than to set the GRH pointer in the WC to null
so the length cannot be used to do this. Another alternative would be
that the LRH indicates whether the GRH was actually present.

Isn't the sense of GRH presence on receive needed for reversible paths ?
How is this indicated ? 

> However, when local_completions() generates a wc from software,
> the byte_len field does not include the grh. 
> Here's a patch.

I will deal with this after the above is understood so the patch is
complete for this.

Thanks for pointing this out.

-- Hal