From: Jacob Keller <jacob.e.keller@intel.com>
To: Jason Xing <kerneljasonxing@gmail.com>,
Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Michal Kubiak <michal.kubiak@intel.com>,
<intel-wired-lan@lists.osuosl.org>,
<maciej.fijalkowski@intel.com>, <netdev@vger.kernel.org>,
<przemyslaw.kitszel@intel.com>, <aleksander.lobakin@intel.com>,
<anthony.l.nguyen@intel.com>
Subject: Re: [PATCH iwl-net] ice: fix incorrect counter for buffer allocation failures
Date: Mon, 11 Aug 2025 14:31:39 -0700 [thread overview]
Message-ID: <c5b09040-0484-484c-a8b7-0675b97c3b9f@intel.com> (raw)
In-Reply-To: <CAL+tcoAwKcy-E6LkLhwvKA9+es5RuFmg4+kPZ8dV08-s-VopPA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3283 bytes --]
On 8/9/2025 6:08 AM, Jason Xing wrote:
> On Sat, Aug 9, 2025 at 5:38 PM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
>>
>> Dear Michal,
>>
>>
>> Thank you for your patch.
>>
>>
>> Am 08.08.25 um 17:53 schrieb Michal Kubiak:
>>> Currently, the driver increments `alloc_page_failed` when buffer allocation fails
>>> in `ice_clean_rx_irq()`. However, this counter is intended for page allocation
>>> failures, not buffer allocation issues.
>>>
>>> This patch corrects the counter by incrementing `alloc_buf_failed` instead,
>>> ensuring accurate statistics reporting for buffer allocation failures.
>>>
>>> Fixes: 2fba7dc5157b ("ice: Add support for XDP multi-buffer on Rx side")
>>> Reported-by: Jacob Keller <jacob.e.keller@intel.com>
>>> Suggested-by: Paul Menzel <pmenzel@molgen.mpg.de>
>>
>> Thank you, but I merely asked to send in the patch separately and didn’t
>> spot the error. So, I’d remove the tag, but you add the one at the end.
>>
>>> Signed-off-by: Michal Kubiak <michal.kubiak@intel.com>
>
> Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
>
>>> ---
>>> drivers/net/ethernet/intel/ice/ice_txrx.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c
>>> index 93907ab2eac7..1b1ebfd347ef 100644
>>> --- a/drivers/net/ethernet/intel/ice/ice_txrx.c
>>> +++ b/drivers/net/ethernet/intel/ice/ice_txrx.c
>>> @@ -1337,7 +1337,7 @@ static int ice_clean_rx_irq(struct ice_rx_ring *rx_ring, int budget)
>>> skb = ice_construct_skb(rx_ring, xdp);
>>> /* exit if we failed to retrieve a buffer */
>>> if (!skb) {
>>> - rx_ring->ring_stats->rx_stats.alloc_page_failed++;
>>> + rx_ring->ring_stats->rx_stats.alloc_buf_failed++;
>>> xdp_verdict = ICE_XDP_CONSUMED;
>>> }
>>> ice_put_rx_mbuf(rx_ring, xdp, ntc, xdp_verdict);
>>
>> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
>>
>>
>> Kind regards,
>>
>> Paul
>>
>>
>> PS: A little off-topic: As this code is present since v6.3-rc1, I
>> wonder, why this has not been causing any user visible issues in the
>> last two years. Can somebody explain this?
>>
>
> From my limited experience, upgrading to the new kernel (like v6.x) is
> not an easy thing. Plus not that many people monitor the driver
> counter on the machine with the ice driver loaded. Sometimes we
> neglect this error because it doesn't harm the real and overall
> workload even when the allocation fails. Things like this sometimes
> happen in other areas :)
>
Exactly this. An end user is unlikely to know the difference between the
buffer allocated vs page allocated failures. Even if they see the
counters going up, how would they know that the counter going up was a bug?
This counter really is just for user visibility into a problem
occurring. Reporting the right counter is critical from a developer
perspective as we might use the fact that one but not the other is going
up in an attempt to isolate issues.. but the end user is unlikely to
ever notice without code inspection.
> Thanks,
> Jason
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
next prev parent reply other threads:[~2025-08-11 21:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-08 15:53 [PATCH iwl-net] ice: fix incorrect counter for buffer allocation failures Michal Kubiak
2025-08-08 23:25 ` Jacob Keller
2025-08-09 9:34 ` Paul Menzel
2025-08-09 13:08 ` Jason Xing
2025-08-11 21:31 ` Jacob Keller [this message]
2025-08-11 8:16 ` [Intel-wired-lan] " Loktionov, Aleksandr
[not found] ` <PH0PR11MB5013285B7475C7F6ABEC1E4E9632A@PH0PR11MB5013.namprd11.prod.outlook.com>
2025-08-21 6:22 ` Singh, PriyaX
2025-08-21 6:35 ` Singh, PriyaX
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c5b09040-0484-484c-a8b7-0675b97c3b9f@intel.com \
--to=jacob.e.keller@intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kerneljasonxing@gmail.com \
--cc=maciej.fijalkowski@intel.com \
--cc=michal.kubiak@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pmenzel@molgen.mpg.de \
--cc=przemyslaw.kitszel@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).