[openib-general] Nitpicking: IB spec 1.2

[Michael S. Tsirkin]

Hello!
Quoting r. Hal Rosenstock (halr at voltaire.com) "Re: [openib-general] Nitpicking: IB spec 1.2":
> 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 ? 

I thought IB_WC_GRH in wc flags is used to indicate the GRH
presence. Right?

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