Linux Documentation
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: tactii@gmail.com
Cc: Simon Horman <horms@kernel.org>,
	intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com,
	aleksander.lobakin@intel.com, andrew+netdev@lunn.ch,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, corbet@lwn.net, skhan@linuxfoundation.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH iwl-next 1/8] e1000e: add jumbo Rx CRC stripping
Date: Thu,  3 Sep 2026 11:27:30 +0100	[thread overview]
Message-ID: <20260903102730.578872-1-horms@kernel.org> (raw)
In-Reply-To: <20260830232146.36948-2-tactii@gmail.com>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev/#/patchset/20260830232146.36948-2-tactii@gmail.com?part=1
---
e1000e: add jumbo Rx CRC stripping
    
When the hardware is configured to not strip the FCS (CrcStripping=0),
the jumbo Rx path would deliver frames with the FCS still attached.
Follow the standard path's convention by stripping the FCS at EOP and
leaving it out of the byte count.

> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 844f31ab37ad4..599600ad695cd 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -1631,13 +1631,23 @@ static bool e1000_clean_jumbo_rx_irq(struct e1000_ring *rx_ring, int *work_done,
>  			}
>  		}
>  
> +		/* strip the Ethernet CRC; it may span fragments */
> +		if (!(adapter->flags2 & FLAG2_CRC_STRIPPING) &&
> +		    !(netdev->features & NETIF_F_RXFCS))
> +			pskb_trim(skb, skb->len - 4);
> +
>  		/* Receive Checksum Offload */
>  		e1000_rx_checksum(adapter, staterr, skb);
>  
>  		e1000_rx_hash(netdev, rx_desc->wb.lower.hi_dword.rss, skb);
>  
> -		/* probably a little skewed due to removing CRC */
>  		total_rx_bytes += skb->len;
> +		/* If configured to store CRC, keep the FCS bytes out of the
> +		 * total_rx_bytes counter
> +		 */
> +		if (!(adapter->flags2 & FLAG2_CRC_STRIPPING) &&
> +		    (netdev->features & NETIF_F_RXFCS))
> +			total_rx_bytes -= 4;

[Severity: Medium]
Could these lockless evaluations of adapter->flags2 and netdev->features get
out of sync if userspace changes features via ethtool while a packet is being
processed?

If a concurrent change occurs between the first check and this second check,
it appears it could lead to an inconsistent state where a packet's payload is
incorrectly truncated by 4 bytes, or where the byte statistics are overcounted
or undercounted by 4 bytes.

>  		total_rx_packets++;
>  
>  		/* eth type trans needs skb->data to point to something */

  parent reply	other threads:[~2026-09-03 10:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-30 23:21 [PATCH iwl-next 0/8] e1000e: use page pool Matt Vollrath
2026-08-30 23:21 ` [PATCH iwl-next 1/8] e1000e: add jumbo Rx CRC stripping Matt Vollrath
2026-08-31  5:54   ` Loktionov, Aleksandr
2026-09-03 10:27   ` Simon Horman [this message]
2026-09-03 15:56     ` Matt Vollrath
2026-08-30 23:21 ` [PATCH iwl-next 2/8] e1000e: dump pages for jumbo Rx buffers Matt Vollrath
2026-08-30 23:21 ` [PATCH iwl-next 3/8] e1000e: prevent race between PM and reset task Matt Vollrath
2026-08-30 23:21 ` [PATCH iwl-next 4/8] e1000e: remove packet-split Rx path Matt Vollrath
2026-08-30 23:21 ` [PATCH iwl-next 5/8] e1000e: always use jumbo " Matt Vollrath
2026-08-30 23:21 ` [PATCH iwl-next 6/8] e1000e: disable NAPI while interface is down Matt Vollrath
2026-09-03 10:27   ` Simon Horman
2026-09-03 15:43     ` Matt Vollrath
2026-08-30 23:21 ` [PATCH iwl-next 7/8] e1000e: use libeth page_pool for Rx Matt Vollrath
2026-08-30 23:21 ` [PATCH iwl-next 8/8] e1000e: return skbs to NAPI cache Matt Vollrath

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=20260903102730.578872-1-horms@kernel.org \
    --to=horms@kernel.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=skhan@linuxfoundation.org \
    --cc=tactii@gmail.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