On 6/8/2021 1:47 AM, Leon Romanovsky wrote:
On Mon, Jun 07, 2021 at 11:54:29PM -0500, Pearson, Robert B wrote:
On 6/7/2021 11:41 PM, Leon Romanovsky wrote:
On Mon, Jun 07, 2021 at 04:50:20PM -0500, Pearson, Robert B wrote:
sorry/this time without the HTML.
======================================================================
ERROR: test_qp_ex_rc_bind_mw (tests.test_qpex.QpExTestCase)
Verify bind memory window operation using the new post_send API.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/rpearson/src/rdma-core/tests/test_qpex.py", line 292, in
test_qp_ex_rc_bind_mw
u.poll_cq(server.cq)
File "/home/rpearson/src/rdma-core/tests/utils.py", line 538, in poll_cq
raise PyverbsRDMAError('Completion status is {s}'.
pyverbs.pyverbs_error.PyverbsRDMAError: Completion status is Memory window
bind error. Errno: 6, No such device or address
This test attempts to bind a type 2 MW to an MR that does not have bind mw
access set and expects the test to succeed.
Does the test break after your MW series? Or will it break not-merged
code yet?
Generally speaking, we expect that developers run rdma-core tests and
fixed/extend them prior to the submission.
Thanks
Bob Pearson
Nope. I don't have real RNICs at home to test. But (see my note to Zhu) the
non extended APIs do set the access flags correctly and the extended test
case does not. The wr_bind_mw() function can't fix this for the test case.
It has to set the access flags when it creates the MR and it didn't. It is
possible that mlx5 doesn't check the bind access flag but that seems
unlikely.
mlx5 devices support MW 1 & 2 and kernel checks that only these types
can be accepted from the user space. This is why mlx5 doesn't need to
check access flags again.
903 static int ib_uverbs_alloc_mw(struct uverbs_attr_bundle *attrs)
904 {
....
927 if (cmd.mw_type != IB_MW_TYPE_1 && cmd.mw_type != IB_MW_TYPE_2) {
928 ret = -EINVAL;
929 goto err_put;
930 }
Thanks
You check the type in alloc_mw but you only check the MR access flags if
MW_DEBUG is set which is not by default. So you would fail a negative
test which we sort of currently have. The second bug in the test which
we found this morning is not correctly setting the op flags in the
create_qp_ex call. According to the man page only the extended
operations set in the op flags are 'implemented' for that QP. Apparently
mlx5 goes ahead and populates them. Makes more sense to me since the API
as described is kind of overwrought and dumb.
Bob
