> -----Original Message----- > From: Song, Yoong Siang <[email protected]> > Sent: Monday, January 19, 2026 9:27 AM > To: Behera, Vivek (DI FA DSP ICC PRC1) <[email protected]>; > Loktionov, Aleksandr <[email protected]>; Keller, Jacob E > <[email protected]>; Nguyen, Anthony L <[email protected]>; > Kitszel, Przemyslaw <[email protected]> > Cc: [email protected]; Behera, Vivek (DI FA DSP ICC PRC1) > <[email protected]> > Subject: RE: [PATCH iwl-net v10] igc: Fix trigger of incorrect irq in > igc_xsk_wakeup > function > > On Saturday, January 17, 2026 11:08 PM, Vivek Behera > <[email protected]> wrote: > >This patch addresses the issue where the igc_xsk_wakeup function was > >triggering an incorrect IRQ for tx-0 when the i226 is configured with > >only 2 combined queues or in an environment with 2 active CPU cores. > >This prevented XDP Zero-copy send functionality in such split IRQ > >configurations. > > > >The fix implements the correct logic for extracting q_vectors saved > >during rx and tx ring allocation and utilizes flags provided by the > >ndo_xsk_wakeup API to trigger the appropriate IRQ. > > > >Fixes: fc9df2a0b520 ("igc: Enable RX via AF_XDP zero-copy") > >Fixes: 15fd021bc427 ("igc: Add Tx hardware timestamp request for AF_XDP > >zero- copy packet") > >Signed-off-by: Vivek Behera <[email protected]> > >Reviewed-by: Jacob Keller <[email protected]> > >Reviewed-by: Aleksandr loktinov <[email protected]> > >Reviewed-by: Piotr Kwapulinski <[email protected]> > >--- > >v1: > >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore. > >kernel.org%2Fintel-wired- > &data=05%7C02%7Cvivek.behera%40siemens.com%7C2 > >239d23f411243a2d52708de57349978%7C38ae3bcd95794fd4addab42e1495d55a > %7C1% > >7C0%7C639044080598030851%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > GkiOnRydW > >UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > % > >7C0%7C%7C%7C&sdata=JscIn6NyDXYdnyW088A7JNjnIID9Z9%2FG26chAQPSz > yw%3D&res > >erved=0 > >lan/[email protected] > RD10. > >PROD.OUTLOOK.COM/ > >v2: > >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore. > >kernel.org%2Fintel-wired- > &data=05%7C02%7Cvivek.behera%40siemens.com%7C2 > >239d23f411243a2d52708de57349978%7C38ae3bcd95794fd4addab42e1495d55a > %7C1% > >7C0%7C639044080598075409%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > GkiOnRydW > >UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > % > >7C0%7C%7C%7C&sdata=WRVJYvn0bUDTN7J8cVPKo2eYtitK7hazEYVGmqqkvs > Y%3D&reser > >ved=0 > >lan/[email protected] > RD10. > >PROD.OUTLOOK.COM/ > >v3: > >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore. > >kernel.org%2Fintel-wired- > &data=05%7C02%7Cvivek.behera%40siemens.com%7C2 > >239d23f411243a2d52708de57349978%7C38ae3bcd95794fd4addab42e1495d55a > %7C1% > >7C0%7C639044080598111943%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > GkiOnRydW > >UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > % > >7C0%7C%7C%7C&sdata=me2sanhvQf%2Fbx%2FVtb%2BrV9vR9o8dUStFJv8M > NM6mPySs%3D > >&reserved=0 > >lan/[email protected] > 11. > >prod.outlook.com/ > >v4: > >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore. > >kernel.org%2Fintel-wired- > &data=05%7C02%7Cvivek.behera%40siemens.com%7C2 > >239d23f411243a2d52708de57349978%7C38ae3bcd95794fd4addab42e1495d55a > %7C1% > >7C0%7C639044080598137405%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > GkiOnRydW > >UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > % > >7C0%7C%7C%7C&sdata=2rYqVNZNhDwa5o1FSvmSXC267VJE66xyD60LSZhroT > I%3D&reser > >ved=0 > >lan/[email protected] > RD10. > >PROD.OUTLOOK.COM/ > >v5: > >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore. > >kernel.org%2Fintel-wired- > &data=05%7C02%7Cvivek.behera%40siemens.com%7C2 > >239d23f411243a2d52708de57349978%7C38ae3bcd95794fd4addab42e1495d55a > %7C1% > >7C0%7C639044080598162513%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > GkiOnRydW > >UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > % > >7C0%7C%7C%7C&sdata=m1ayGPBKlpYN%2FHqsUAHhCZGP2x0X4tiTLDfar9Aj > CR0%3D&res > >erved=0 > >lan/[email protected] > RD10. > >PROD.OUTLOOK.COM/ > >v6: > >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore. > >kernel.org%2Fintel-wired-lan%2F20251211173916.23951-1-&data=05%7C02%7Cv > >ivek.behera%40siemens.com%7C2239d23f411243a2d52708de57349978%7C38ae > 3bcd > >95794fd4addab42e1495d55a%7C1%7C0%7C639044080598182062%7CUnknown > %7CTWFpb > >GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFO > >IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qrIm%2F%2Bt8awy > aQqhOEBP > >vp%2BF4fJY3xJl0lIhJ%2BOJgylM%3D&reserved=0 > >[email protected]/ > >v7: > >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore. > >kernel.org%2Fintel-wired-lan%2F20251212163208.137164-1-&data=05%7C02%7C > >vivek.behera%40siemens.com%7C2239d23f411243a2d52708de57349978%7C38a > e3bc > >d95794fd4addab42e1495d55a%7C1%7C0%7C639044080598199719%7CUnknown > %7CTWFp > >bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > sIkF > >OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=y3qBVJQOuXJmU > Y0rvj8TFA > >ncp7i%2FrD8kdRwXqnOdHLE%3D&reserved=0 > >[email protected]/ > >v8: > >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore. > >kernel.org%2Fintel-wired-lan%2F20251215122052.412327-1-&data=05%7C02%7C > >vivek.behera%40siemens.com%7C2239d23f411243a2d52708de57349978%7C38a > e3bc > >d95794fd4addab42e1495d55a%7C1%7C0%7C639044080598216422%7CUnknown > %7CTWFp > >bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > sIkF > >OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2iKYyIwmju7DxuL > k9QeqzF > >ibtSqDSAcbxBrKcR9O%2BH0%3D&reserved=0 > >[email protected]/ > >v9: > >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore. > >kernel.org%2Fintel-wired-lan%2F20251220110009.137245-1-&data=05%7C02%7C > >vivek.behera%40siemens.com%7C2239d23f411243a2d52708de57349978%7C38a > e3bc > >d95794fd4addab42e1495d55a%7C1%7C0%7C639044080598233633%7CUnknown > %7CTWFp > >bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > sIkF > >OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HgAtdG1Pi6iKho6 > YTHJVcc > >buz81CmWsnBCGnAmI%2F%2B0E%3D&reserved=0 > >[email protected]/ > > > >changelog: > >v1 > >- Inital description of the Bug and steps to reproduce with RTC > >Testbench > >- Test results after applying the patch > >v1 -> v2 > >- Handling of RX and TX Wakeup in igc_xsk_wakeup for a split IRQ > >configuration > >- Removal of igc_trigger_rxtxq_interrupt (now redundant) > >- Added flag to igc_xsk_wakeup function call in igc_ptp_free_tx_buffer > >v2 -> v3 > >- Added 'Fixes:' tags for the relevant commits. > >- Added reviewer > >v3 -> v4 > >- Added reviewer > >v4 -> v5 > >- Updated comment style from multi-star to standard linux convention > >v5 -> v6 > >- Resolve formatting issues highlighted by reviewers > >- Try to include version histroy as defined in netdev guidelines > >- Included review suggestions from Przemyslaw > >- Added reviewers > >v6 -> v7 > >- Included review suggestions from Przemyslaw missed in v6 > >v7 -> v8 > >- Modified sequence to complete all error checks for rx and tx > > before updating napi states and triggering irq > >v8 -> v9 > >- Included review feedback and suggestions from Tony and Siang > >v9 -> v10 > >- Introduced a simplified logic for sequential check for RX and TX > >--- > > drivers/net/ethernet/intel/igc/igc_main.c | 32 ++++++++++++++++------- > >drivers/net/ethernet/intel/igc/igc_ptp.c | 3 ++- > > 2 files changed, 24 insertions(+), 11 deletions(-) > > > >diff --git a/drivers/net/ethernet/intel/igc/igc_main.c > >b/drivers/net/ethernet/intel/igc/igc_main.c > >index 7aafa60ba0c8..16a61d432296 100644 > >--- a/drivers/net/ethernet/intel/igc/igc_main.c > >+++ b/drivers/net/ethernet/intel/igc/igc_main.c > >@@ -6908,28 +6908,29 @@ static int igc_xdp_xmit(struct net_device *dev, > >int num_frames, > > return nxmit; > > } > > > >-static void igc_trigger_rxtxq_interrupt(struct igc_adapter *adapter, > >- struct igc_q_vector *q_vector) > >+static u32 igc_sw_irq_prep(struct igc_q_vector *q_vector) > > { > >- struct igc_hw *hw = &adapter->hw; > > u32 eics = 0; > > > >- eics |= q_vector->eims_value; > >- wr32(IGC_EICS, eics); > >+ if (!napi_if_scheduled_mark_missed(&q_vector->napi)) > >+ eics = q_vector->eims_value; > >+ > >+ return eics; > > } > > > > int igc_xsk_wakeup(struct net_device *dev, u32 queue_id, u32 flags) { > > struct igc_adapter *adapter = netdev_priv(dev); > >- struct igc_q_vector *q_vector; > >+ struct igc_hw *hw = &adapter->hw; > > struct igc_ring *ring; > >+ u32 eics = 0; > > > > if (test_bit(__IGC_DOWN, &adapter->state)) > > return -ENETDOWN; > > > > if (!igc_xdp_is_enabled(adapter)) > > return -ENXIO; > >- > >+ /* Check if queue_id is valid. Tx and Rx queue numbers are always > >+same > >*/ > > if (queue_id >= adapter->num_rx_queues) > > return -EINVAL; > > > >@@ -6938,9 +6939,20 @@ int igc_xsk_wakeup(struct net_device *dev, u32 > >queue_id, u32 flags) > > if (!ring->xsk_pool) > > return -ENXIO; > > > >- q_vector = adapter->q_vector[queue_id]; > >- if (!napi_if_scheduled_mark_missed(&q_vector->napi)) > >- igc_trigger_rxtxq_interrupt(adapter, q_vector); > >+ if (flags & XDP_WAKEUP_RX) > >+ eics |= igc_sw_irq_prep(ring->q_vector); > >+ > >+ if (flags & XDP_WAKEUP_TX) { > >+ /* for IGC_FLAG_QUEUE_PAIRS, this will be NOP as NAPI has > >+ * been already marked with NAPIF_STATE_MISSED > >+ */ > > The code looked good to me, but I am not understand this comment. > Can you help to explain why the NAPI will be marked as NAPIF_STATE_MISSED? If the napi was running it will be marked as missed and if napi is not scheduled the function would return false preparing the eics value for soft irq trigger > per my understanding, for IGC_FLAG_QUEUE_PAIRS, rx_ ring->q_vector will be > equal to tx_ ring->q_vector, thus, no harm for eics to "OR" the same value > twice. > Am I right? Yes. Exactly for the IGC_FLAG_QUEUE_PAIRS the q_vector its napi are The same for rx and tx so calling napi_if_scheduled_mark_missed the second time would not have change anything. If IGC_FLAG_QUEUE_PAIRS is not active the q_vector extracted from the tx_ring would be different and so would be it's napi which will be then used as the argument in napi_if_scheduled_mark_missed > > >+ ring = adapter->tx_ring[queue_id]; > >+ eics |= igc_sw_irq_prep(ring->q_vector); > >+ } > >+ > >+ if (eics) > >+ /* Cause software interrupt */ > >+ wr32(IGC_EICS, eics); > > > > return 0; > > } > >diff --git a/drivers/net/ethernet/intel/igc/igc_ptp.c > >b/drivers/net/ethernet/intel/igc/igc_ptp.c > >index b7b46d863bee..df2e500a4d7e 100644 > >--- a/drivers/net/ethernet/intel/igc/igc_ptp.c > >+++ b/drivers/net/ethernet/intel/igc/igc_ptp.c > >@@ -550,7 +550,8 @@ static void igc_ptp_free_tx_buffer(struct > >igc_adapter *adapter, > > tstamp->buffer_type = 0; > > > > /* Trigger txrx interrupt for transmit completion */ > >- igc_xsk_wakeup(adapter->netdev, tstamp->xsk_queue_index, 0); > >+ igc_xsk_wakeup(adapter->netdev, tstamp->xsk_queue_index, > >+ XDP_WAKEUP_TX); > > > > return; > > } > >-- > >2.34.1
Re: [Intel-wired-lan] [PATCH iwl-net v10] igc: Fix trigger of incorrect irq in igc_xsk_wakeup function
Behera, VIVEK via Intel-wired-lan Mon, 19 Jan 2026 02:00:42 -0800
- [Intel-wired-lan] [PATCH iwl-net v10] ig... Vivek Behera via Intel-wired-lan
- Re: [Intel-wired-lan] [PATCH iwl-ne... Song, Yoong Siang
- Re: [Intel-wired-lan] [PATCH iw... Behera, VIVEK via Intel-wired-lan
- Re: [Intel-wired-lan] [PATC... Song, Yoong Siang
- Re: [Intel-wired-lan] [... Behera, VIVEK via Intel-wired-lan
