Page MenuHomeFreeBSD

mpi3mr: Update consumerindex of admin and op reply queues after every 100 replies
ClosedPublic

Authored by chandrakanth.patil_broadcom.com on Mar 19 2024, 11:35 AM.
Tags
None
Referenced Files
Unknown Object (File)
Jun 6 2024, 3:54 PM
Unknown Object (File)
May 27 2024, 9:46 AM
Unknown Object (File)
May 10 2024, 2:50 AM
Unknown Object (File)
May 5 2024, 11:57 AM
Unknown Object (File)
Apr 26 2024, 4:43 PM
Unknown Object (File)
Apr 8 2024, 7:43 PM
Unknown Object (File)
Apr 8 2024, 6:29 PM
Unknown Object (File)
Mar 22 2024, 4:53 PM
Subscribers
None

Details

Summary

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

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Mar 21 2024, 8:15 AM
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.