On Sun, Jul 27, 2025 at 10:16:10PM +0800, Jason Xing wrote: > Hi Simon, > > On Sun, Jul 27, 2025 at 9:55 PM Simon Horman <[email protected]> wrote: > > > > On Sun, Jul 27, 2025 at 06:06:55PM +0800, Jason Xing wrote: > > > Hi Paul, > > > > > > On Sun, Jul 27, 2025 at 4:36 PM Paul Menzel <[email protected]> wrote: > > > > > > > > Dear Jason, > > > > > > > > > > > > Thank you for the improved version. > > > > > > > > Am 26.07.25 um 09:03 schrieb Jason Xing: > > > > > From: Jason Xing <[email protected]> > > > > > > > > > > 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 <[email protected]> > > > > > Reviewed-by: Larysa Zaremba <[email protected]> > > > > > --- > > > > > Link: > > > > > https://lore.kernel.org/all/[email protected]/ > > > > > 1. use 'negative overflow' instead of 'underflow' (Willem) > > > > > 2. add reviewed-by tag (Larysa) > > > > > 3. target iwl-net branch (Larysa) > > > > > 4. add the reason why the patch adds likely() (Larysa) > > > > > --- > > > > > drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 4 +++- > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c > > > > > b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c > > > > > index ac58964b2f08..7b941505a9d0 100644 > > > > > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c > > > > > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c > > > > > @@ -398,7 +398,7 @@ static bool ixgbe_xmit_zc(struct ixgbe_ring > > > > > *xdp_ring, unsigned int budget) > > > > > dma_addr_t dma; > > > > > u32 cmd_type; > > > > > > > > > > - while (budget-- > 0) { > > > > > + while (likely(budget)) { > > > > > if (unlikely(!ixgbe_desc_unused(xdp_ring))) { > > > > > work_done = false; > > > > > break; > > > > > @@ -433,6 +433,8 @@ static bool ixgbe_xmit_zc(struct ixgbe_ring > > > > > *xdp_ring, unsigned int budget) > > > > > xdp_ring->next_to_use++; > > > > > if (xdp_ring->next_to_use == xdp_ring->count) > > > > > xdp_ring->next_to_use = 0; > > > > > + > > > > > + budget--; > > > > > } > > > > > > > > > > if (tx_desc) { > > > > > > > > Reviewed-by: Paul Menzel <[email protected]> > > > > > > > > Is this just the smallest fix, and the rewrite to the more idiomatic for > > > > loop going to be done in a follow-up? > > > > > > Thanks for the review. But I'm not that sure if it's worth a follow-up > > > patch. Or if anyone else also expects to see a 'for loop' version, I > > > can send a V3 patch then. I have no strong opinion either way. > > > > I think we have iterated over this enough (pun intended). > > Hhh, interesting. > > > If this patch is correct then lets stick with this approach. > > No problem. Tomorrow I will send the 'for loop' version :)
I meant, I think the while loop is fine. But anything that is correct is fine by me :)
