Maybe it'll be better if we do: static inline bool queue_sig_limit(struct nvme_rdma_queue *queue) { return (++queue->sig_count % (queue->queue_size / 2)) == 0; } And lose the hard-coded 32 entirely. Care to test that?Hello Sigi, I agree with you, we've found a setup where the signalling every queue depth is not enough and we're testing the division by two that seems to work fine till now. In your version in case of queue length > 32 the notifications would be sent less often that they are now. I'm wondering if it will have impact on performance and internal card buffering (it seems that Mellanox buffers are ~100 elements). Wouldn't it create issues? I'd like see the magic constant removed. From what I can see we need to have something not exceeding send buffer of the card but also not lower than the queue depth. What do you think?
I'm not sure what buffering is needed from the device at all in this case, the device is simply expected to avoid signaling completions. Mellanox folks, any idea where is this limitation coming from? Do we need a device capability for it? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
