[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL+tcoBUKmt5mCq4coLkbqT5Ehb+V6NFDcjOErg_8AYHG4fgcg@mail.gmail.com>
Date: Sun, 27 Jul 2025 22:16:10 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Simon Horman <horms@...nel.org>
Cc: Paul Menzel <pmenzel@...gen.mpg.de>, 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,
intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
Jason Xing <kernelxing@...cent.com>
Subject: Re: [Intel-wired-lan] [PATCH v2 iwl-net] ixgbe: xsk: resolve the
negative overflow of budget in ixgbe_xmit_zc
Hi Simon,
On Sun, Jul 27, 2025 at 9:55 PM Simon Horman <horms@...nel.org> 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 <pmenzel@...gen.mpg.de> wrote:
> > >
> > > Dear Jason,
> > >
> > >
> > > Thank you for the improved version.
> > >
> > > Am 26.07.25 um 09:03 schrieb Jason Xing:
> > > > 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>
> > > > ---
> > > > Link: https://lore.kernel.org/all/20250720091123.474-3-kerneljasonxing@gmail.com/
> > > > 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 <pmenzel@...gen.mpg.de>
> > >
> > > 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 :)
Thanks,
Jason
Powered by blists - more mailing lists