> > 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 [EMAIL PROTECTED] only. Makes sense, removed other CCs... - R. _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
