On Fri, Jul 25, 2025 at 6:58 PM Larysa Zaremba <larysa.zaremba@xxxxxxxxx> 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
I see, but this series is built on top of this patch, so in V2 I
should still cook these three patches based on the current patch?
> same, given you have things to change in v2, but the fix can be resent almost
> as it is now (just change the tree).
Got it, I will send it soon as a standalone patch.
Thanks,
Jason
>
> Tony can have a different opinion though.
>
> > Thanks,
> > Jason
> >
