> -----Ursprüngliche Nachricht-----
> Von: Maciej Fijalkowski <[email protected]>
> Gesendet: Dienstag, 20. Januar 2026 13:52
> An: Behera, Vivek (DI FA DSP ICC PRC1) <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; intel-wired-
> [email protected]; [email protected]
> Betreff: Re: [PATCH iwl-net v7] igb: Fix trigger of incorrect irq in 
> igb_xsk_wakeup
> 
> On Tue, Jan 20, 2026 at 08:50:53AM +0100, Vivek Behera wrote:
> > The current implementation in the igb_xsk_wakeup expects the Rx and Tx
> > queues to share the same irq. This would lead to triggering of
> > incorrect irq in split irq configuration.
> > This patch addresses this issue which could impact environments with 2
> > active cpu cores or when the number of queues is reduced to 2 or less
> >
> > cat /proc/interrupts | grep eno2
> >  167:          0          0          0          0 IR-PCI-MSIX-0000:08:00.0
> >  0-edge      eno2
> >  168:          0          0          0          0 IR-PCI-MSIX-0000:08:00.0
> >  1-edge      eno2-rx-0
> >  169:          0          0          0          0 IR-PCI-MSIX-0000:08:00.0
> >  2-edge      eno2-rx-1
> >  170:          0          0          0          0 IR-PCI-MSIX-0000:08:00.0
> >  3-edge      eno2-tx-0
> >  171:          0          0          0          0 IR-PCI-MSIX-0000:08:00.0
> >  4-edge      eno2-tx-1
> >
> > Furthermore it uses the flags input argument to trigger either rx, tx
> > or both rx and tx irqs as specified in the ndo_xsk_wakeup api
> > documentation
> >
> > Fixes: 80f6ccf9f116 ("igb: Introduce XSK data structures and helpers")
> > Signed-off-by: Vivek Behera <[email protected]>
> > Reviewed-by: Aleksandr Loktionov <[email protected]>
> 
> Hi Vivek,
> 
> I gave you my acked-by on v6. I don't feel obliged to call out such things 
> but since
> we have completely changed approach of fixing things here, Aleksandr do you 
> want
> to keep your review tag? If so then please go through the code again.
Hi Maciej,

I am okay with removing Aleksander's Reviewed-by Tag if it is no longer valid. 
I had also mentioned during the discussion on the v5 thread that  
due to the changed approach, you might even consider submitting a fresh patch 
by dropping mine. 
Nevertheless, from my perspective it is critical that we can start upstreaming 
the fixes included
in this patch along with the igc for my Stakeholders who are planning to 
release their Products on Siemens IPCs with I210 and i226
cards in the next quarter.  
I just want to communicate the urgency on this topic.    
> 
> Thanks!
> 
> > Suggested-by: Maciej Fijalkowski <[email protected]>
> > ---
> > v1:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fintel-wired-lan%2F20251212131454.124116-1-vivek.behera%4
> >
> 0siemens.com%2F&data=05%7C02%7Cvivek.behera%40siemens.com%7C3219ce1
> 35f
> >
> 81466db29e08de5822a99d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7
> C63
> >
> 9045103048376499%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW
> UsIlYiO
> >
> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7
> C
> >
> %7C%7C&sdata=bFd0kGibsg8vv0%2BCsCV5HU%2FccorvAphaprPLtfAgnA8%3D&
> reserv
> > ed=0
> > v2:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fintel-wired-lan%2F20251215115416.410619-1-vivek.behera%4
> >
> 0siemens.com%2F&data=05%7C02%7Cvivek.behera%40siemens.com%7C3219ce1
> 35f
> >
> 81466db29e08de5822a99d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7
> C63
> >
> 9045103048417392%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW
> UsIlYiO
> >
> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7
> C
> >
> %7C%7C&sdata=4IzCdXUlEaWODsWCru2F3xIy02NwfoPYTtsnLjHN1Q8%3D&reser
> ved=0
> > v3:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fintel-wired-lan%2F20251220114936.140473-1-vivek.behera%4
> >
> 0siemens.com%2F&data=05%7C02%7Cvivek.behera%40siemens.com%7C3219ce1
> 35f
> >
> 81466db29e08de5822a99d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7
> C63
> >
> 9045103048455269%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW
> UsIlYiO
> >
> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7
> C
> >
> %7C%7C&sdata=2%2BhI0oizG3q8bl3dxLTnFbXH%2FpMAdQonSl9rNLIyCFc%3D&r
> eserv
> > ed=0
> > v4:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fintel-wired-lan%2F20251222115747.230521-1-vivek.behera%4
> >
> 0siemens.com%2F&data=05%7C02%7Cvivek.behera%40siemens.com%7C3219ce1
> 35f
> >
> 81466db29e08de5822a99d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7
> C63
> >
> 9045103048497301%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW
> UsIlYiO
> >
> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7
> C
> >
> %7C%7C&sdata=oJXJyzmla5rvnYNu4OHS0b7bYY%2BjOXe66QxrT79YfJs%3D&re
> served
> > =0
> > v5:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fintel-wired-lan%2F20260112130349.1737901-1-vivek.behera%
> >
> 40siemens.com%2F&data=05%7C02%7Cvivek.behera%40siemens.com%7C3219ce
> 135
> >
> f81466db29e08de5822a99d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
> 7C6
> >
> 39045103048534301%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW
> UsIlYi
> >
> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0
> %7
> >
> C%7C%7C&sdata=Z%2BYULMIoUWG8BfRHegGxiWVE39on%2BctH7YTbzkfz%2F
> Co%3D&res
> > erved=0
> > v6:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fintel-wired-lan%2F20260117145112.2088217-1-vivek.behera%
> >
> 40siemens.com%2F&data=05%7C02%7Cvivek.behera%40siemens.com%7C3219ce
> 135
> >
> f81466db29e08de5822a99d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
> 7C6
> >
> 39045103048568401%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW
> UsIlYi
> >
> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0
> %7
> >
> C%7C%7C&sdata=mnZAzSk6WTEAN15HSWdsDzJvx6QetZLg7akqqnjrkiU%3D&re
> served=
> > 0
> >
> > changelog:
> > v1
> > - Initial description of the Bug and fixes made in the patch
> >
> > v1 -> v2
> > - Handling of RX and TX Wakeup in igc_xsk_wakeup for a split IRQ
> > configuration
> > - Review suggestions by Aleksander: Modified sequence to complete all
> >   error checks for rx and tx before updating napi states and
> > triggering irqs
> > - Corrected trigger of TX and RX interrupts over E1000_ICS (non msix
> > use case)
> > - Added define for Tx interrupt trigger bit mask for E1000_ICS
> >
> > v2 -> v3
> > - Included applicable feedback and suggestions from igc patch
> > - Fixed logic in updating eics value when  both TX and RX need wakeup
> >
> > v3 -> v4
> > - Added comments to explain trigerring of both TX and RX with active
> > queue pairs
> > - Fixed check of xsk pools in if statement
> >
> > v4 -> v5
> > - Introduced a simplified logic for sequential check for RX and TX
> >
> > v5 -> v6
> > - Further simplifications suggested by Maciej
> > - Included review suggestions from reviewers
> >
> > v6 -> v7
> > - Removed redundant braces
> > - Updated comment block to improve explanation of implemented logic
> > ---
> >  drivers/net/ethernet/intel/igb/igb_xsk.c | 38
> > +++++++++++++++++++-----
> >  1 file changed, 30 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/igb/igb_xsk.c
> > b/drivers/net/ethernet/intel/igb/igb_xsk.c
> > index 30ce5fbb5b77..ce4a7b58cad2 100644
> > --- a/drivers/net/ethernet/intel/igb/igb_xsk.c
> > +++ b/drivers/net/ethernet/intel/igb/igb_xsk.c
> > @@ -524,6 +524,16 @@ bool igb_xmit_zc(struct igb_ring *tx_ring, struct
> xsk_buff_pool *xsk_pool)
> >     return nb_pkts < budget;
> >  }
> >
> > +static u32 igb_sw_irq_prep(struct igb_q_vector *q_vector) {
> > +   u32 eics = 0;
> > +
> > +   if (!napi_if_scheduled_mark_missed(&q_vector->napi))
> > +           eics = q_vector->eims_value;
> > +
> > +   return eics;
> > +}
> > +
> >  int igb_xsk_wakeup(struct net_device *dev, u32 qid, u32 flags)  {
> >     struct igb_adapter *adapter = netdev_priv(dev); @@ -542,20 +552,32
> > @@ int igb_xsk_wakeup(struct net_device *dev, u32 qid, u32 flags)
> >
> >     ring = adapter->tx_ring[qid];
> >
> > -   if (test_bit(IGB_RING_FLAG_TX_DISABLED, &ring->flags))
> > -           return -ENETDOWN;
> > -
> >     if (!READ_ONCE(ring->xsk_pool))
> >             return -EINVAL;
> >
> > -   if (!napi_if_scheduled_mark_missed(&ring->q_vector->napi)) {
> > +   if (flags & XDP_WAKEUP_TX) {
> > +           if (test_bit(IGB_RING_FLAG_TX_DISABLED, &ring->flags))
> > +                   return -ENETDOWN;
> > +
> > +           eics |= igb_sw_irq_prep(ring->q_vector);
> > +   }
> > +
> > +   if (flags & XDP_WAKEUP_RX) {
> > +           /* If IGB_FLAG_QUEUE_PAIRS is active, the q_vector
> > +            * and NAPI is shared between RX and TX.
> > +            * If NAPI is already running it would be marked as missed
> > +            * from the TX path, making this RX call a NOP
> > +            */
> > +           ring = adapter->rx_ring[qid];
> > +           eics |= igb_sw_irq_prep(ring->q_vector);
> > +   }
> > +
> > +   if (eics) {
> >             /* Cause software interrupt */
> > -           if (adapter->flags & IGB_FLAG_HAS_MSIX) {
> > -                   eics |= ring->q_vector->eims_value;
> > +           if (adapter->flags & IGB_FLAG_HAS_MSIX)
> >                     wr32(E1000_EICS, eics);
> > -           } else {
> > +           else
> >                     wr32(E1000_ICS, E1000_ICS_RXDMT0);
> > -           }
> >     }
> >
> >     return 0;
> > --
> > 2.34.1
> >

Reply via email to