On Wed, Jan 21, 2026 at 07:02:47AM +0000, Behera, VIVEK wrote: > > > > -----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.
Patch is fine, just add my ack. > 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 > > >
