[ofa-general] Re: [PATCH 06/13] IB/ehca: Set SEND_GRH flag for all non-LL UD QPs on eHCA2

[Roland Dreier]

 > > What decides if a QP is LL or not?

 > Currently we use a high bit in the QP type, which is not how we
 > want to keep it permanently.  What would you suggest, add two
 > additional LL QP types, or change something more fundamental in
 > libibverbs and kernel ib core?  We think we can get along quite
 > well with the existing parameters in the current create QP.  The
 > current user-kernel interface is ok for these new QPs for post_send
 > + post_recv, but unfortunately the libibverbs userspace calls don't
 > match exactly how the LL queues are to be used.  We would need
 > something like the LL QP interface in libehca in libibverbs to keep
 > that interface generic.

Yes, using the high bit of the QP type is yucky.  If there's no need
for LL QPs in the kernel, then at least the internal part (libehca ->
ehca driver) could be cleaned up by using a flag in the create_qp
udata.  I think that's worth doing.

I also think it's worth exposing some more flags for the libibverbs
ibv_create_qp function.  mlx4 could potentially use a hint from the
user that certain QPs want low latency, so we could share this with ehca.

But I'm not sure I know what you mean by "how the LL queues are to be
used".  Could you expand on that?  I assume it has something to do
with ehcau_send_wr_trigger(), ehcau_recv_wr_trigger() etc. but I don't
know what they do.  Having libehca export functions that are called
directly by applications definitely seems wrong to me.

 > We didn't see a usage yet for LL QP in kernel, so maybe we should continue
 > that discussion on general at openfabrics only.

Makes sense, removed other CCs...

 - R.