RE: [PATCH iwl-next] ixgbe: fix ITR value overflow in adaptive interrupt throttling

Loktionov, Aleksandr
2026-04-03T16:12:13Z

> -----Original Message-----
> From: Simon Horman <horms@kernel.org>
> Sent: Friday, April 3, 2026 3:19 PM
> To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> Cc: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; netdev@vger.kernel.org
> Subject: Re: [PATCH iwl-next] ixgbe: fix ITR value overflow in
> adaptive interrupt throttling
>
> On Fri, Mar 27, 2026 at 08:30:45AM +0100, Aleksandr Loktionov wrote:
> > ixgbe_update_itr() packs a mode flag (IXGBE_ITR_ADAPTIVE_LATENCY,
> bit
> > 7) and a usecs delay (bits [6:0]) into an unsigned int, then stores
> it
> > in ring_container->itr which is u8. Values above 0xFF wrap,
> > corrupting both the delay and the mode-flag on the next readback.
> >
> > Separate the mode bits from the usecs sub-field; clamp only the
> latter
> > to [0, IXGBE_ITR_ADAPTIVE_LATENCY - 1] via min_t(unsigned int, ...)
> so
> > overflow cannot bleed into bit 7. Add a WARN_ONCE() when the raw
> > usecs value exceeds U8_MAX so out-of-range ITR computations are
> > visible in dmesg during development and testing.
> >
> > Fixes: b4ded8327fea ("ixgbe: Update adaptive ITR algorithm")
> > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>
> Somehow - perhaps because there is no m/n notation present in the []
> in the subject - Patchwork has treated each patch in this series as
> it's own patch-set.
>
> And in the case of this patch, it didn't apply - I assume because in
> order to do so an earlier patch in the series needs to be present.
>
> So CI didn't run on this patch :(

Good day, Simon

I have a bunch of simple /* independent */ patches for submission every week.
Whis way you'd recommend to send them to ease /* and accelerate review */ ?

1. submit one by one
2. submit as a batch by one git command (with the same internal main ID tag internally)
3. imagine a cover latter and submit as a patch-set

Thank you
Alex