Re: [PATCH net-next v3 05/15] ibmveth: Refactor RX interrupt control for MQ RX queues

[mingming cao <mmc@linux.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]


On 7/14/26 5:43 AM, Simon Horman wrote:
> On Mon, Jul 06, 2026 at 12:35:53PM -0700, Mingming Cao wrote:
>> Queue 0 and subordinate RX queues use different interrupt control
>> interfaces in PHYP:
>>
>>    - queue 0: h_vio_signal() after h_register_logical_lan()
>>    - queue N: H_VIOCTL against the queue handle/hwirq mapping
>>
>> The current code is single-queue oriented and cannot safely scale to
>> multiple RX queues in poll completion and open/close IRQ setup.
>>
>> Introduce queue-indexed interrupt helpers:
>>
>>    ibmveth_enable_irq(adapter, queue_index)
>>    ibmveth_disable_irq(adapter, queue_index)
>>    ibmveth_setup_rx_interrupts()
>>    ibmveth_cleanup_rx_interrupts()
>>
>> These helpers centralize queue0-vs-subordinate dispatch and make IRQ
>> lifecycle symmetric across open/close and future resize paths.
>>
>> request_irq() is wired with &adapter->napi[i] as dev_id per queue, so
>> interrupt ownership follows the NAPI instance that services that RX
>> queue.
>>
>> Signed-off-by: Mingming Cao<mmc@linux.ibm.com>
>> Reviewed-by: Dave Marquardt<davemarq@linux.ibm.com>
*

Hi Simon,


Thanks for the thorough review to the entire series!

*
> Although it is added later in this patch set, I believe linux/irqdomain.h
> needs to be included in this patch so that irq_dispose_mapping is defined.
*

Thanks, will fix in v4 — move linux/irqdomain.h into this patch

where irq_dispose_mapping() is first used.

*
> Also, I think it would be best to add these helpers in the same patch(es)
> that they are first used.  As this will avoid temporal compiler warnings
> about declared but otherwise unused functions. Similarly for patch 13/15.
*

Agreed. In v4 I will introduce each helper in the same patch that

first calls it from open()/close() (and the same rule for resize /

set_channels), move linux/irqdomain.h with the first

irq_dispose_mapping() use, and open()/close() will be converted 
incrementally; there

will not be a separate MQ-only open path before multi_queue is enabled

*
> Overall, please make sure that when each patch of the series is applied
> no new warnings or errors are introduced for allmodconfig W=1 builds.
>
> FWIIW, I exercised this using gcc 16.1 from
> https://www.kernel.org/pub/tools/crosstool/
>
> ...

**

*Will do — v4 will be checked so each patch applies cleanly under*

*

allmodconfig W=1 (no new warnings/errors), including with a

current crosstool gcc.

*
*

Thanks,

Mingming

*

[-- Attachment #2: Type: text/html, Size: 9223 bytes --]