[openib-general] Re: libmthca problem: max_inline_size

[Michael S. Tsirkin]

Quoting Roland Dreier <rolandd at cisco.com>:
> Subject: Re: libmthca problem: max_inline_size
> 
>     > 2. Return the actual QP capability in create qp command.
>     >    This is an ABI change, although the library can be made to work in a
>     >    backward compatible way.
>     > 3. Add a command (device specific) to query the max descriptor size supported
>     >    by the HCA (returned by query dev lim) and calculate max_inline_size
>     >    based on that.
>     >    Again, this is an ABI change.
> 
>     > I am inclining towards the second option (2.) since this way the
>     > resulting capability calculations will be all in one place in kernel.
> 
> I think we need a combination of 2. and 3. because the WQE shifts and
> buffers from userspace need to match up with the kernel.

Its slightly unclear to me what is meant by "the combination of 2 and 3".
With 2., the kernel returns back the actual capabilities supported, so
we dont need to know the max descriptor size in userspace, since
kernel will do the checks and return the actual qp capabilities
back to us.

Maybe we'll see as we work on the implementation.

> For 3. there's no need to a completely new command.  We could return
> extra device-dependent values from the GET_CONTEXT command, or even
> just add some sysfs attributes to the mthca device (similar to the
> fw_ver attribute).
> 
>     > There's a similiar problem in mthca_arbel_post_send where the
>     > inline data size is checked against the expression
> 
>     > 	int max_size = (1 << qp->sq.wqe_shift) - sizeof *seg - size * 16;
> 
>     > I would imagine the way to fix that is to add a max_inline_size field
>     > to the mthca_qp structure and is that instead of 1 << qp->sq.wqe_shift.
> 
> Yes, that makes sense.

Okay ... do you want me and Jack to prepare such a patch, or would
you rather do it yourself?

-- 
MST