[openib-general] [PATCH 1/2] (fixed) mthca: max_inline_data support

[Rimmer, Todd]

> Here's an updated patch - I'll be offline till Sunday and I hope
> it's good to go. Please note there's a companion patch for libmthca,
> ([PATCH 2/2]) which is also needed to actually use this stuff.
> 
> Quoting r. Roland Dreier <roland at topspin.com>:
> > Subject: Re: [openib-general] [PATCH 1/2] mthca: 
> max_inline_data support
> > 
> > Thanks... does it make sense to set the max_inline_data value for
> > kernel QPs but then not support posting inline data?
> 
> You are right: max_inline_data in init_attr shall be left 0
> until posting inline data in kernel is supported. Fixed.
> 
> > Also should we add some error checking against the HCA's maximum WQE
> > size?
> 
> I added such a check.
> 
> 
> Support max_inline_data parameter for userspace QPs.
> Check max_send_sge/max_recv_sge/max_inline_data against the HCA's
> limits.
> 

Regarding inline data in posted wqes, this decision can be automatically made for user QPs and for some kernel QPs.  Hence the API need not be exposed in user space.

If all MRs in the Protection domain have CPU Virtual == IO Virtual, then the post_wqe routine can automatically inline the data as appropriate.  Given this situation, the IO Virtual address in the work request scatter gather list can be used as a direct CPU address to copy data into the WQE.

For user space QPs, CPU Virtual should always == IO Virtual.  This is because:
register mr and register shared mr should use the CPU virtual as the IO Virtual.

In the kernel, a flag can be kept per PD indicating if CPU Virtual == IO Virtual.  Only for PDs using physical memory regions, would this condition be false.

This approach relieves applications from dealing with the inline decisions, and it can permit the verbs driver to inline data in some additional cases (such as when there are fewer scatter gather entries in a WQE, hence making more room for inline data).

Todd Rimmer