Roland Dreier wrote:
In other words this check catches common bugs and makes them a gazillion times
easier to find and fix. So unless the performance impact is extreme, I'm
inclined to leave it
okay, lets leave this like that for unless someone comes with
performance data that shows this is
Roland Dreier wrote:
I do think it is quite common to see this WQ overflow check trigger, even for
kernel code
mmm, why is that common? typically there's a higher layer to which the
IB ULP advertises some sort of maximal number of credits (e.g in the
SCSI case, iser and srp specify the
mmm, why is that common? typically there's a higher layer to which the
IB ULP advertises some sort of maximal number of credits (e.g in the
SCSI case, iser and srp specify the maximal number of commands in the
scsi host template) or the ULP informs a higher layer that no more
sends can
I wonder if the overflow check could be removed all together and be
left to the ULP (kernel is trusted environment...) is there any risk
in doing so? this way the WR posting code will not experience
contention with the poll WC code on the CQ lock.
We could do that I guess if it's a
thanks, applied.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Roland Dreier wrote:
thanks, applied.
With this not being a regression, I see that it went into your for-next branch
and as such I assume will be available by 2.6.34. Are you fine with the patch
going into the -stable series?
Or.
--
To unsubscribe from this list: send the line unsubscribe
the post recv flow should check wq overflow using the recv and not the send cq
Signed-off-by: Or Gerlitz ogerl...@voltaire.com
diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
index 989555c..2a97c96 100644
--- a/drivers/infiniband/hw/mlx4/qp.c
+++
