[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL+tcoAAq9ccjUybzxoYbVG6i3Ev1C098aGKWvAvKMUeFyG3Tw@mail.gmail.com>
Date: Sun, 10 Aug 2025 20:22:46 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: anthony.l.nguyen@...el.com, przemyslaw.kitszel@...el.com,
larysa.zaremba@...el.com, andrew+netdev@...n.ch, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, bjorn@...nel.org,
maciej.fijalkowski@...el.com
Cc: intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH v2 iwl-net] ixgbe: xsk: resolve the negative overflow of
budget in ixgbe_xmit_zc
On Sat, Jul 26, 2025 at 3:04 PM Jason Xing <kerneljasonxing@...il.com> wrote:
>
> From: Jason Xing <kernelxing@...cent.com>
>
> Resolve the budget negative overflow which leads to returning true in
> ixgbe_xmit_zc even when the budget of descs are thoroughly consumed.
>
> Before this patch, when the budget is decreased to zero and finishes
> sending the last allowed desc in ixgbe_xmit_zc, it will always turn back
> and enter into the while() statement to see if it should keep processing
> packets, but in the meantime it unexpectedly decreases the value again to
> 'unsigned int (0--)', namely, UINT_MAX. Finally, the ixgbe_xmit_zc returns
> true, showing 'we complete cleaning the budget'. That also means
> 'clean_complete = true' in ixgbe_poll.
>
> The true theory behind this is if that budget number of descs are consumed,
> it implies that we might have more descs to be done. So we should return
> false in ixgbe_xmit_zc to tell napi poll to find another chance to start
> polling to handle the rest of descs. On the contrary, returning true here
> means job done and we know we finish all the possible descs this time and
> we don't intend to start a new napi poll.
>
> It is apparently against our expectations. Please also see how
> ixgbe_clean_tx_irq() handles the problem: it uses do..while() statement
> to make sure the budget can be decreased to zero at most and the negative
> overflow never happens.
>
> The patch adds 'likely' because we rarely would not hit the loop codition
> since the standard budget is 256.
>
> Fixes: 8221c5eba8c1 ("ixgbe: add AF_XDP zero-copy Tx support")
> Signed-off-by: Jason Xing <kernelxing@...cent.com>
> Reviewed-by: Larysa Zaremba <larysa.zaremba@...el.com>
Hi Tony,
Any update here? Thanks! I'm asking because I'm ready to send an afxdp
patch series based on the patch :)
Thanks,
jason
Powered by blists - more mailing lists