Roland Dreier wrote:
> Without this fix, incoming GSI packets on port 2 gets invalid pkey index in
the completion,
> which prevent from the mad layer to send back a response.
Does this explain the problems that someone saw when using all port 2
of a connectx setup?
Yes. without this mask the value of the pkey_index was 0x80. In the
function build_mlx_header
there is a call to ib_get_cached_pkey which failed because the pkey
index was out of range
(i sent you a patch that check the return value). This failure caused to
uninitialized pkey value to
be sent in the MAD response ....
Why does it only affect port 2?
> - wc->pkey_index = be32_to_cpu(cqe->immed_rss_invalid) >> 16;
> + wc->pkey_index = (u16)(be32_to_cpu(cqe->immed_rss_invalid) &
0x7f);
It seems the (u16) cast here is doubly useless, since wc->pkey_index
is already u16, and we're masking with 0x7f anyway.
If you want i can send a new patch without the casting ...
By the way, will it always work to mask with 0x7f? Or is it possible
that the P_Key table might have more than 128 entries?
Yes, 0x7f should be enough for the ConnectX HCA because it supports 128
pkey entries per port.
(this line will be written in the next version of the ConnectX PRM)
Dotan
_______________________________________________
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
