Linux-HyperV List
 help / color / mirror / Atom feed
From: Sahil Chandna <sahilchandna@linux.microsoft.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-rdma@vger.kernel.org, linux-hyperv@vger.kernel.org,
	weh@linux.microsoft.com
Subject: Re: [PATCH net-next] net: mana: Add support to process throttled EQEs
Date: Mon, 12 Oct 2026 12:20:18 +0530	[thread overview]
Message-ID: <b884be07-3e76-4256-a8e6-70b8540ab492@linux.microsoft.com> (raw)
In-Reply-To: <sashiko-outbox-165094@kernel.org>

On 09-10-2026 14:03, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] mana: RDMA queue stalls due to dropped throttle events
> --
> 
> commit 49b4827fa426b6ae0b8759a5984d01f44b8db5e1
> Author: Sahil Chandna <sahilchandna@linux.microsoft.com>
> 
> net: mana: Add support to process throttled EQEs
> 
> This commit adds support for processing throttled EQEs of type 4 when an
> event queue nears full capacity. The driver advertises the
> GDMA_DRV_CAP_FLAG_1_THROTTLED_EVENT_QUEUE capability and attempts to schedule
> the CQs associated with a throttled EQE. CQs are tracked in a new child_cq
> array initialized when creating a CQ.
> 
>> diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
>> index ae0ed700b3b93..b8e5ad2c6d312 100644
>> --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
>> +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
>> @@ -747,6 +747,18 @@ void mana_gd_free_service_wq(struct gdma_context *gc)
>>  	gc->service_wq = NULL;
>>  }
>>  
>> +static void mana_gd_schedule_eq_cqs(struct gdma_queue *eq)
>> +{
>> +	struct gdma_queue *cq;
>> +	u8 i;
>> +
>> +	for (i = 0; i < GDMA_EQ_MAX_CHILD_CQ; i++) {
>> +		cq = rcu_dereference(eq->eq.child_cq[i]);
>> +		if (cq && cq->cq.callback)
>> +			cq->cq.callback(cq->cq.context, cq);
> 
> [Severity: High]
> When a GDMA_EQE_THROTTLE event is processed, this function attempts to notify
> the CQs. Will RDMA CQs receive these notifications?
> 
> RDMA CQs do not appear to be added to child_cq, which might cause their
> notifications to be entirely dropped and result in RDMA queue stalls.
> 
>> +	}
>> +}
>> +
> 

The issue for RDMA CQ handling were highlighted in internal AI reviews
as well and I discussed this with Wei Hu from RDMA about this.

Before the patch, all throttled EQEs were getting dropped, the patch
aims to address this gap by handling the throttled EQE which were
reproduced in internal testing.The RDMA side throttling is going to be
handled separately by Wei.

> [ ... ]
> 
>> @@ -1063,17 +1080,41 @@ static void mana_gd_create_cq(const struct gdma_queue_spec *spec,
>>  			      struct gdma_queue *queue)
>>  {
>>  	u32 log2_num_entries = ilog2(spec->queue_size / GDMA_CQE_SIZE);
>> +	struct gdma_queue *parent;
>> +	u8 i;
>>  
>>  	queue->head |= INITIALIZED_OWNER_BIT(log2_num_entries);
>> -	queue->cq.parent = spec->cq.parent_eq;
>> +	parent = spec->cq.parent_eq;
>> +	queue->cq.parent = parent;
>>  	queue->cq.context = spec->cq.context;
>>  	queue->cq.callback = spec->cq.callback;
>> +
>> +	if (!parent)
>> +		return;
>> +
>> +	/* For throttled EQE store the child CQ */
>> +	for (i = 0; i < GDMA_EQ_MAX_CHILD_CQ; i++)
>> +		if (!rcu_access_pointer(parent->eq.child_cq[i])) {
>> +			rcu_assign_pointer(parent->eq.child_cq[i], queue);
>> +			return;
>> +		}
> 
> [Severity: High]
> Does this logic handle RDMA CQs correctly?
> 
> RDMA CQs are created with a NULL parent_eq (via mana_ib_create_kernel_queue),
> which causes this function to return early without populating the child_cq
> array.
> 
> Additionally, if an EQ has more than GDMA_EQ_MAX_CHILD_CQ (which is 2) CQs
> attached, which is common in RDMA workloads, this loop will silently return
> without adding the additional CQs. Can this lead to lost completions?
> 
>>  }
> 
The handling of RDMA CQ and attaching to parent EQ will be done in
separate series, as discussed.> [ ... ]
> 
>> diff --git a/include/net/mana/gdma.h b/include/net/mana/gdma.h
>> index c610fc1067e0d..03fe9395604d6 100644
>> --- a/include/net/mana/gdma.h
>> +++ b/include/net/mana/gdma.h
>> @@ -776,7 +785,8 @@ enum {
>>  	 GDMA_DRV_CAP_FLAG_1_HANDLE_STALL_SQ_RECOVERY | \
>>  	 GDMA_DRV_CAP_FLAG_1_EQ_MSI_UNSHARE_MULTI_VPORT | \
>>  	 GDMA_DRV_CAP_FLAG_1_DYN_INTERRUPT_MODERATION | \
>> -	 GDMA_DRV_CAP_FLAG_1_NON_CONTIGUOUS_BUFFERS)
>> +	 GDMA_DRV_CAP_FLAG_1_NON_CONTIGUOUS_BUFFERS | \
>> +	 GDMA_DRV_CAP_FLAG_1_THROTTLED_EVENT_QUEUE)
> 
> [Severity: High]
> Since this patch globally advertises throttling support, the hardware might
> send throttle events on RDMA EQs when they are heavily loaded.
> 
The cap bit does not enable throttle events. The device generates
THROTTLE EQEs for any EQ created with throttle_limit, whether or not the
driver sets cap bits so the RDMA throttle would not be a consequence of
this patch.

> Given that RDMA EQs are initialized with a log2_throttle_limit in
> mana_ib_create_eqs(), will enabling this capability cause RDMA workloads to
> stall if their throttle events are dropped due to the missing child_cq mapping
> in mana_gd_create_cq()?
> Yes, it is possible but it is not tied to capability bits, and handling
of RDMA throttled events is a planned task to be handled in separate
series.

Regards,
Sahil

  reply	other threads:[~2026-10-12  6:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08  8:33 [PATCH net-next] net: mana: Add support to process throttled EQEs Sahil Chandna
2026-10-08  8:39 ` netdev-bot+sinfo
2026-10-09 14:02   ` Sahil Chandna
2026-10-09  8:33 ` sashiko-bot
2026-10-12  6:50   ` Sahil Chandna [this message]
2026-10-12  9:09 ` netdev-bot+sashiko
2026-10-13 15:08   ` Sahil Chandna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b884be07-3e76-4256-a8e6-70b8540ab492@linux.microsoft.com \
    --to=sahilchandna@linux.microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=weh@linux.microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox