quoted

+int megasas_blk_mq_poll(struct Scsi_Host *shost, unsigned int
+queue_num) {
+
+	struct megasas_instance *instance;
+	int num_entries = 0;
+	struct fusion_context *fusion;
+
+	instance = (struct megasas_instance *)shost->hostdata;
+
+	fusion = instance->ctrl_context;
+
+	queue_num = queue_num + instance->low_latency_index_start;
+
+	if (!atomic_add_unless(&fusion->busy_mq_poll[queue_num], 1, 1))
+		return 0;
+
+	num_entries = complete_cmd_fusion(instance, queue_num, NULL);
+	atomic_dec(&fusion->busy_mq_poll[queue_num]);
+
+	return num_entries;
+}
+
  /**
   * megasas_enable_irq_poll() - enable irqpoll
   * @instance:			Adapter soft state

I really wonder if we need the atomic counter here.
complete_cmd_fusion() will already return the number of completed
commands, so the only benefit we're getting is to avoid calling
complete_cmd_fusion() if no commands are pending.
But if no commands are pending we are necessarily off the hot path anyway,
so calling complete_cmd_fusion() here (and have it return 0) should matter
much.
Am I wrong?

Hannes -

I think you are talking about busy_mq_poll atomic counter. This counter
avoid race condition of having complete_cmd_fusion() (for specific
queue_number) called from multiple context.
It is possible that we have hctx0 (which is in polled mode) with multiple
cpu_mask. Without this counter, more than one poll thread can attempt to
poll on hctx0 and we will end up in panic or some other issues. This counter
will make sure poll is executed from only one context and if poll on
specific hctx is active, another poll will simply return as very first poll
will take care the completion.

Kashyap

Otherwise: All thumbs up for this work. Very good job.

Cheers,

Hannes
--
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809
(AG Nürnberg), Geschäftsführer: Felix Imendörffer