[ofw] RE: [PATCH] ib_qp_create_t

[Sean Hefty]

I agree with this.  If the requested limit cannot be met, the QP creation should
fail.  Creating the QP and requiring the user to query to see what they got is
less than obvious behavior.

 

The HCA attributes should include max inline size.

 

  _____  

From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Fab Tillier
Sent: Wednesday, March 26, 2008 1:08 AM
To: Reuven Amitai; ofw at lists.openfabrics.org
Subject: [ofw] RE: [PATCH] ib_qp_create_t

 

Can the HCA set it to more than requested?  Or is it only allowed to set it to
less?


Having the HCA set it to less introduces a different behavior than the rest of
the QP creation parameters, where the call fails if the value is too big (max
WR, max SGE, etc).  Requiring a call to query in order to find out whether the
requested inline data was granted seems a bit cumbersome.

 

-Fab

 

From: Reuven Amitai [mailto:reuven at mellanox.co.il] 
Sent: Wednesday, March 26, 2008 1:06 AM
To: Fab Tillier; ofw at lists.openfabrics.org
Subject: RE: [PATCH] ib_qp_create_t

 

Max inline is input from the user to the HCA but the HCA may set it less than
the user request (due to HCA limitations).

I don't think there is one optimal value for max_inline in every situation that
HW can set if the user want to use inline data.

ib_qp_create_t is only input and the user should query the qp in order to get
the real value of max inline.

 

Reuven.

 

  _____  

From: Fab Tillier [mailto:ftillier at windows.microsoft.com] 
Sent: Wednesday, March 26, 2008 9:32 AM
To: Reuven Amitai; ofw at lists.openfabrics.org
Subject: RE: [PATCH] ib_qp_create_t

Should max inline be an input or an output?  The optimal size of inline data is
something the HW knows, not the consumer.  So perhaps it would make sense for
the consumer to indicate that they want to use inline data, and then the HCA
driver to return the amount of inline data available?

 

-Fab

 

From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Reuven Amitai
Sent: Wednesday, March 26, 2008 12:30 AM
To: ofw at lists.openfabrics.org
Subject: [ofw] [PATCH] ib_qp_create_t

 

Hi,

 

The patch add sq_max_inline member to ib_qp_create_t structure in order to
enable setting max_inline 

(currently, there is no way to guarantee max inline size in qp creation
directly)

we'll need to increase all the relevant interfaces' versions in the next release
(because ib_qp_create_t is contained in IOCTL structure(s))

 

Reuven

 

Index: hw/mthca/user/mlnx_ual_qp.c

===================================================================

--- hw/mthca/user/mlnx_ual_qp.c     (revision 992)

+++ hw/mthca/user/mlnx_ual_qp.c     (working copy)

@@ -120,7 +120,7 @@

      attr.cap.max_recv_wr          = p_create_attr->rq_depth;

      attr.cap.max_send_sge         = p_create_attr->sq_sge;

      attr.cap.max_recv_sge         = p_create_attr->rq_sge;

-     attr.cap.max_inline_data      = 0;              /* absent in IBAL */

+     attr.cap.max_inline_data      = p_create_attr->sq_max_inline;

      attr.qp_type                                          =
p_create_attr->qp_type;

      attr.sq_sig_all                                 =
p_create_attr->sq_signaled;

      

Index: inc/iba/ib_types.h

===================================================================

--- inc/iba/ib_types.h  (revision 992)

+++ inc/iba/ib_types.h  (working copy)

@@ -9755,6 +9755,7 @@

 {

      ib_qp_type_t                  qp_type;

 

+     uint32_t                      sq_max_inline;

      uint32_t                      sq_depth;

      uint32_t                      rq_depth;

      uint32_t                      sq_sge;

@@ -9772,6 +9773,10 @@

 *    type

 *          Specifies the type of queue pair to create.

 *

+*    sq_max_inline

+*          Maximum payload that can be inlined directly in a WQE, eliminating

+*          protection checks and additional DMA operations.

+*

 *    sq_depth

 *          Indicates the requested maximum number of work requests that may be

 *          outstanding on the queue pair's send queue.  This value must be less

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20080327/b642a2b9/attachment.html>