Re: [PATCH net-next v3 5/5] bnge: make NQ0 persistent across open/stop cycles

[Bhargava Chenna Marreddy]

Hi Jakub,

Thanks for the feedback.

On Wed, Oct 21, 2026 at 2:04 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>
> On Wed, 14 Oct 2026 01:36:45 +0530 Bhargava Marreddy wrote:
> > NQ0's NAPI keeps running while the interface is down
>
> Sounds like abuse of netdev infra. Creative reuse of this sort makes it
> extremely painful to add stack-level features.

Understood. I agree NAPI shouldn't outlive the open state.

For context: NQ0 differs from the other NQs. Besides Rx/Tx, it also
handles firmware async events and HWRM completions (and MPC/PSP soon).
I kept NAPI running while down so these non-datapath events are still
serviced, independent of the netdev state.

A dedicated async-only vector would cost one MSI-X per PF/VF, taking
it away from Rx/Tx queues, which I'd like to avoid.

What I propose for v4:

1. NAPI for NQ0 is added in ndo_open and deleted in ndo_stop, like
   every other NQ.
2. NQ0's IRQ stays requested across open/stop:
   - When netdev is UP: The IRQ handler schedules NAPI, which handles
     Rx/Tx, async (including link), and HWRM events.
   - When netdev is DOWN: There is no NAPI instance. The IRQ handler
     queues a work item that handles async and HWRM events.
3. Mode switches happen only in open/stop, so only one context
   consumes NQ0 at a time:
   - open: quiesce the IRQ, flush the work item, then enable NAPI.
   - stop: disable NAPI, then allow the work item again.

That way no NAPI context exists outside open/stop, and the vector is
still shared between async events and the datapath.

Would this be acceptable, or do you see a problem with it? If you'd
prefer something different (e.g. a dedicated vector despite the cost),
I'm happy to go that way.

I'll hold off on v4 until we agree on the direction.

Thanks,
Bhargava, Marreddy

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature