On 7/25/2025 3:57 AM, Larysa Zaremba wrote:
On Fri, Jul 25, 2025 at 07:18:11AM +0800, Jason Xing wrote:
Hi Tony,
On Fri, Jul 25, 2025 at 4:21 AM Tony Nguyen <anthony.l.nguyen@xxxxxxxxx> wrote:
On 7/20/2025 2:11 AM, Jason Xing wrote:
From: Jason Xing <kernelxing@xxxxxxxxxxx>
Resolve the budget underflow 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 underflow
never happens.
Fixes: 8221c5eba8c1 ("ixgbe: add AF_XDP zero-copy Tx support")
Hi Jason,
Seems like this one should be split off and go to iwl-net/net like the
other similar ones [1]? Also, some of the updates made to the other
series apply here as well?
The other three patches are built on top of this one. If without the
patch, the whole series will be warned because of build failure. I was
thinking we could backport this patch that will be backported to the
net branch after the whole series goes into the net-next branch.
Or you expect me to cook four patches without this one first so that
you could easily cherry pick this one then without building conflict?
Thanks,
Tony
[1]
https://lore.kernel.org/netdev/20250723142327.85187-1-kerneljasonxing@xxxxxxxxx/
Regarding this one, should I send a v4 version with the current patch
included? And target [iwl-net/net] explicitly as well?
I'm not sure if I follow you. Could you instruct me on how to proceed
next in detail?
What I usually do is send the fix as soon as I have it. While I prepare and test
the series, the fix usually manages to get into the tree. Advise you do the
same, given you have things to change in v2, but the fix can be resent almost
as it is now (just change the tree).
Tony can have a different opinion though.
I agree. Normally in these situations, send the fix first and after that
one is
applied, the other patches can be sent.
This patch would've fit in nice with the other series, however, as that
one is already in process and this one can standalone. I would send this
fix by itself.
Thanks,
Tony
