netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.e.keller@intel.com>
To: Jesse Brandeburg <jbrandeb@kernel.org>, <netdev@vger.kernel.org>
Cc: Jesse Brandeburg <jbrandeburg@cloudflare.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	IWL <intel-wired-lan@lists.osuosl.org>,
	"Przemek Kitszel" <przemyslaw.kitszel@intel.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	"Brett Creeley" <brett.creeley@intel.com>
Subject: Re: [PATCH net v1] ice: stop counting UDP csum mismatch as rx_errors
Date: Tue, 2 Dec 2025 14:08:36 -0800	[thread overview]
Message-ID: <85edbf2d-f1f7-4286-8c11-a0c8ce715696@intel.com> (raw)
In-Reply-To: <20251201233853.15579-1-jbrandeb@kernel.org>


[-- Attachment #1.1: Type: text/plain, Size: 2993 bytes --]



On 12/1/2025 3:38 PM, Jesse Brandeburg wrote:
> From: Jesse Brandeburg <jbrandeburg@cloudflare.com>
> 
> Since the beginning, the Intel ice driver has counted receive checksum
> offload mismatches into the rx_errors member of the rtnl_link_stats64
> struct. In ethtool -S these show up as rx_csum_bad.nic.
> 
> I believe counting these in rx_errors is fundamentally wrong, as it's
> pretty clear from the comments in if_link.h and from every other statistic
> the driver is summing into rx_errors, that all of them would cause a
> "hardware drop" except for the UDP checksum mismatch, as well as the fact
> that all the other causes for rx_errors are L2 reasons, and this L4 UDP
> "mismatch" is an outlier.
> 
> A last nail in the coffin is that rx_errors is monitored in production and
> can indicate a bad NIC/cable/Switch port, but instead some random series of
> UDP packets with bad checksums will now trigger this alert. This false
> positive makes the alert useless and affects us as well as other companies.
> 
> This packet with presumably a bad UDP checksum is *already* passed to the
> stack, just not marked as offloaded by the hardware/driver. If it is
> dropped by the stack it will show up as UDP_MIB_CSUMERRORS.
> 
> And one more thing, none of the other Intel drivers, and at least bnxt_en
> and mlx5 both don't appear to count UDP offload mismatches as rx_errors.
> 
> Here is a related customer complaint:
> https://community.intel.com/t5/Ethernet-Products/ice-rx-errros-is-too-sensitive-to-IP-TCP-attack-packets-Intel/td-p/1662125
> 
> Fixes: 4f1fe43c920b ("ice: Add more Rx errors to netdev's rx_error counter")
> Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
> Cc: Jake Keller <jacob.e.keller@intel.com>
> Cc: IWL <intel-wired-lan@lists.osuosl.org>
> Signed-off-by: Jesse Brandeburg <jbrandeburg@cloudflare.com>
> --
> I am sending this to net as I consider it a bug, and it will backport
> cleanly.
> ---

Its fine with me. I can't find anything explaining why we originally
chose to put these in rx_errors, and I think its better to align with
other drivers and vendors. I suspect its just as "this is an error, it
obviously goes in rx_errors" even though its of a completely different kind.

Acked-by: Jacob Keller <jacob.e.keller@intel.com>

>  drivers/net/ethernet/intel/ice/ice_main.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> index 86f5859e88ef..d004acfa0f36 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -6995,7 +6995,6 @@ void ice_update_vsi_stats(struct ice_vsi *vsi)
>  		cur_ns->rx_errors = pf->stats.crc_errors +
>  				    pf->stats.illegal_bytes +
>  				    pf->stats.rx_undersize +
> -				    pf->hw_csum_rx_error +
>  				    pf->stats.rx_jabber +
>  				    pf->stats.rx_fragments +
>  				    pf->stats.rx_oversize;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

  reply	other threads:[~2025-12-02 22:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-01 23:38 [PATCH net v1] ice: stop counting UDP csum mismatch as rx_errors Jesse Brandeburg
2025-12-02 22:08 ` Jacob Keller [this message]
2025-12-05  8:26 ` [Intel-wired-lan] " Loktionov, Aleksandr
2025-12-05 19:05   ` Jesse Brandeburg
2025-12-05 20:56     ` Loktionov, Aleksandr
2025-12-05 22:44       ` jbrandeburg
2025-12-08 22:20         ` Jacob Keller

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=85edbf2d-f1f7-4286-8c11-a0c8ce715696@intel.com \
    --to=jacob.e.keller@intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=brett.creeley@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jbrandeb@kernel.org \
    --cc=jbrandeburg@cloudflare.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --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).