On 12/28/2018 1:53 AM, Hannes Reinecke wrote:
Have you considered making 'LPFC_EQ_DELAY_MSECS' configurable?
It looks to me as if it would introduce a completion latency; having it
configurable would allow us to check and possibly modify this.
It could be configurable if desired.
It shouldn't introduce a latency, although it may leave a latency set
longer than it perhaps should be. The define is the heartbeat polling
interval. The heartbeat samples the statistics of the number of times
entered per interval and adjust the interrupt delay accordingly.
There's an interesting interplay that goes on between the interrupt
generation (EQ firing) and the CQ processing and rearming - which in
most cases, especially when per-cpu affinity is happening as it should,
results in almost no need to set anything other than no delay on the
interrupt (it's always immediate). After an interrupt occurs, any delay
timer is started, but although the interrupt handler completes, no
further interrupt will be generated until the CQ processing completes
and rearms the CQ. As things get higher under load, the CQ processing
becomes longer and still doesn't generate a lot of actual interupts.
Where this logic was needed was for a case where the platform was
ignoring the interrupt affinity hints, putting multiple vectors (which
should have been on different cpus) on a single cpu. I have not seen
this happen on upstream kernels, but the same source on an older distro
kernel showed this. In this case, the interrupts (additive across the
multiple vectors) had to be monitored and reduced so the cpu didn't
spend all its time in the interrupt handlers.
-- james
