From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: <netdev-bot+sashiko@kernel.org>
Cc: <p@1g4.org>, <intel-wired-lan@lists.osuosl.org>,
<netdev@vger.kernel.org>, <anthony.l.nguyen@intel.com>,
<przemyslaw.kitszel@intel.com>, <andrew+netdev@lunn.ch>,
<davem@davemloft.net>, <edumazet@kernel.org>, <kuba@kernel.org>,
<pabeni@redhat.com>, <ast@kernel.org>, <daniel@iogearbox.net>,
<hawk@kernel.org>, <john.fastabend@gmail.com>, <sdf@fomichev.me>,
<vedang.patel@intel.com>, <jithu.joseph@intel.com>,
<andre.guedes@intel.com>, <aleksandr.loktionov@intel.com>,
<avigailx.dahan@intel.com>, <linux-kernel@vger.kernel.org>,
<bpf@vger.kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH net v3 1/2] igc: only strip RX timestamp header from first buffer
Date: Fri, 30 Oct 2026 12:45:06 +0100 [thread overview]
Message-ID: <auSDQtz8l8hzzr86@boxer> (raw)
In-Reply-To: <179331704005.3134.12545545223659652020@kernel.org>
On Thu, Oct 29, 2026 at 11:37:20PM +0000, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider.
>
> Critical: 0 · High: 1 · Medium: 0 · Low: 0
>
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
>
> - [High] At this commit by itself, the new first-buffer test `!skb &&
> igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)` in igc_clean_rx_irq()…
>
> --
>
> igc: only strip RX timestamp header from first buffer
>
> igc_clean_rx_irq() used to subtract IGC_TS_HDR_LEN from every descriptor
> with TSIP set, which truncated multi-buffer packets. With this patch the
> timestamp header is only stripped when skb is NULL, which the commit treats
> as marking the first buffer of a new packet.
>
> Link: https://lore.kernel.org/all/20260625-igb-rx-ts-fix-v3-1-99b3efa08dca@aweta.nl/
>
> > diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
> > index 1fb5f3cbe93c5..41b293dc10c3a 100644
> > --- a/drivers/net/ethernet/intel/igc/igc_main.c
> > +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> > @@ -2639,7 +2639,8 @@ static int igc_clean_rx_irq(struct igc_q_vector *q_vector, const int budget)
> >
> > pktbuf = page_address(rx_buffer->page) + rx_buffer->page_offset;
> >
> > - if (igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {
> > + if (!skb &&
> > + igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {
> > ctx.rx_ts = pktbuf;
> > pkt_offset = IGC_TS_HDR_LEN;
> > size -= IGC_TS_HDR_LEN;
>
> [Severity: High]
>
> Is skb == NULL a reliable first-buffer marker when an XDP program is
> attached? The commit message says:
>
> Only consume the timestamp header when skb is NULL, which identifies the
> first buffer of a new packet.
>
> Suppose igc_xdp_run_prog() returns IGC_XDP_CONSUMED, IGC_XDP_TX or
> IGC_XDP_REDIRECT for the first, non-EOP buffer of a multi-descriptor frame.
> Then no skb is built, and igc_clean_rx_irq() moves on to the continuation
> descriptor with skb still NULL:
>
> /* fetch next buffer in frame if non-eop */
> if (igc_is_non_eop(rx_ring, rx_desc))
> continue;
>
> The continuation descriptor still has TSIP set, so this check strips
> IGC_TS_HDR_LEN a second time. If that descriptor holds fewer than 16 bytes,
> can the unsigned size wrap here?
>
> The continuation buffer then goes through the new-frame path:
>
> if (!skb) {
> xdp_init_buff(&ctx.xdp, truesize, &rx_ring->xdp_rxq);
> xdp_prepare_buff(&ctx.xdp, pktbuf - igc_rx_offset(rx_ring),
> igc_rx_offset(rx_ring) + pkt_offset,
> size, true);
>
> In that case the XDP program would see a data_end about 4 GiB past data.
> On XDP_PASS, the same size would reach igc_build_skb() or
> igc_construct_skb(), and the __skb_put() there does not check it.
>
> At this commit, XDP with multi-descriptor frames looks possible on kernels
> with PAGE_SIZE >= 8192. igc_set_rx_mode() only clamps RLPML under the
> small-page #if:
>
> #if (PAGE_SIZE < 8192)
> if (adapter->max_frame_size <= IGC_MAX_FRAME_BUILD_SKB)
> rlpml = IGC_MAX_FRAME_BUILD_SKB;
> #endif
> wr32(IGC_RLPML, rlpml);
>
> On large-page kernels, RLPML therefore stays at MAX_JUMBO_FRAME_SIZE while
> igc_rx_bufsz() returns IGC_RXBUFFER_2048. igc_xdp_set_prog() only checks
> dev->mtu > ETH_DATA_LEN, not the hardware receive length limit.
>
> This needs RX hardware timestamping enabled, an XDP program that returns a
> non-PASS verdict for a first buffer, and a peer that sends frames larger
> than about 2032 bytes.
>
> The next patch in this series, "igc: fix AF_XDP receive buffer size for 2K
> UMEM chunks", adds igc_set_rlpml(). It caps RLPML at 1526 bytes whenever
> XDP is enabled, whatever PAGE_SIZE is. It is called from igc_setup_rctl()
> and igc_xdp_set_prog(). With that change, XDP frames always fit in a single
> descriptor, and skb == NULL becomes a correct first-buffer marker.
Wow - finally.
>
> This patch is tagged Cc: stable and could be backported on its own. Should
> it depend on that follow-up change, or should the two patches be swapped in
> the series?
How would we make sure both commits from this set get actually backported
together?
>
> --
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261028083344.3047350-1-p%401g4.org
next prev parent reply other threads:[~2026-10-30 11:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 8:34 [PATCH net v3 0/2] igc: fix RX timestamp handling and AF_XDP buffer sizing Paul Moses
2026-10-28 8:35 ` [PATCH net v3 1/2] igc: only strip RX timestamp header from first buffer Paul Moses
2026-10-29 23:37 ` netdev-bot+sashiko
2026-10-30 11:45 ` Maciej Fijalkowski [this message]
2026-10-30 16:47 ` Paul Moses
2026-10-30 19:00 ` Maciej Fijalkowski
2026-10-28 8:35 ` [PATCH net v3 2/2] igc: fix AF_XDP receive buffer size for 2K UMEM chunks Paul Moses
2026-10-29 8:09 ` Loktionov, Aleksandr
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=auSDQtz8l8hzzr86@boxer \
--to=maciej.fijalkowski@intel.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andre.guedes@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=ast@kernel.org \
--cc=avigailx.dahan@intel.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=hawk@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jithu.joseph@intel.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev-bot+sashiko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=p@1g4.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=sdf@fomichev.me \
--cc=stable@vger.kernel.org \
--cc=vedang.patel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.