Instead of updating the ConsumerIndex of the Admin and Operational ReplyQueues
after processing all replies in the queue, it will now be periodically updated
after processing every 100 replies
Details
Details
- Reviewers
imp sumit.saxena_broadcom.com chs markj mav
Diff Detail
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
| sys/dev/mpi3mr/mpi3mr.c | ||
|---|---|---|
| 4391 | What happens if we have less than 100 completions? Can we fail to reach 100 each time and wind up never updating? | |
| sys/dev/mpi3mr/mpi3mr.c | ||
|---|---|---|
| 4391 | As I see it will write to the register the old style after the loop. I suppose it should be better that doing it once as before, but I just wonder where the 100 is coming from and how bug is it relative to the queue size? Can the queue happen to be small(er)? Could it better to use something flexible like sc->num_admin_replies / 4, or the queue can never me that small for it to matter? | |
| sys/dev/mpi3mr/mpi3mr.c | ||
|---|---|---|
| 4391 | For the current controller, using a threshold of 100 or one-fourth of the queue depth (QD/4) doesn't affect performance. However, for the upcoming Broadcom next-generation storage controller (not yet submitted upstream), there's an algorithm that relies on this threshold, and 100 is more suitable than one-fourth of the queue depth. Hence, the decision was made to use 100 as the threshold for updating the reply queue consumer index. | |