[openib-general] Some ib_mad.h Redirection Comments

[Sean Hefty]

On Tue, 10 Aug 2004 12:41:47 -0400
Hal Rosenstock <halr at voltaire.com> wrote:

Thanks for the feedback!

> Is it intended that this structure include a pointer to the MAD (struct
> ib_mad *mad) rather than a coalesced buffer and a (total) length ? 

My intention is that the structure should reference the start of the MAD (coalesced or not).  The length is the total length of the buffer referenced by *mad.  In most cases, this would be 256 bytes.  For RMPP MADs, it could be larger.

We can discuss ownership of the ib_mad_recv_wc structure.  For now, I'm assuming that it would be owned by the access layer.  The buffers belong to the user.

Note that I separated the grh to allow using a single grh data buffer for all receives on redirected QPs.
 
> I presume it is a requirement (of the implementation) that out of order
> RMPP segments are reordered before presentation across this interface. 

Correct.  One issue with how the structure is defined is that it currently requires copying the RMPP segments into a single buffer before handing them to the user.  We need to revisit how to avoid this data copy, but still have an interface that's usable for special QPs as well as redirected QPs.

> > (I haven't given up on zero-copy receives; the proposed chaining just needs some additional thought.) 
> > Hopefully, we can begin working towards this API, but continue discussing some of the areas marked 
> > in the file with 'XXX'.
> Maybe these should be in a GSI TODO rather than in this file. 

I will move these into a TODO file.

> > I need to think more about the redirection case, and examine an implementation to see 
> > how much work/policy is in it.  I think that if it is totally transparent to the requestor, 
> > then the API will be unaffected.  Likewise, if it is exposed.  We probably only need to 
> > modify the API if we need to reach some sort of compromise between the implementation 
> > versus the policy.
> At this point, in the interest of moving on, we ought to defer redirect.
> We can live without it in the short term. 

Sounds good to me.


> > struct ib_rmpp_hdr {
> > 	u8	rmpp_version;
> > 	u8	rmpp_type;
> > 	u8	rmpp_flags;
> 
> As this field also contains RespTime, maybe it's name should be something
> more like rmpp_rtime_flags.

Good point.