Re: [PATCH net v2] net/mlx5e: SHAMPO, Fix IP length overflow on large HW GRO sessions

Dragos Tatulea <[email protected]>
Newsgroups org.kernel.vger.linux-rdma,org.kernel.vger.linux-kernel,org.kernel.vger.netdev
Message-ID <[email protected]>

On 20.08.26 01:03, Jakub Kicinski wrote:
> On Mon, 17 Aug 2026 14:16:18 -0400 Tianyu Zuo wrote:
>> mlx5e_hw_gro_skb_has_enough_space() bounds a HW GRO session by the
>> payload held in the skb fragments only. The L3/L4 headers that
>> header-data split placed in the linear area are not accounted for, and
>> the limit is inclusive of GRO_LEGACY_MAX_SIZE.
> 
> This regresses both ipv4-large-rem and ipv6-large-rem on CX7
> 
> # # Exception|   STDERR: Expected {64896 600 600 }, Total 3 packets
> # # Exception|           Received {60840 [!=64896]4656 [!=600]600 }, Total 3 packets.
> 
> we could have fit another MSS into the aggregate, easily.
Uh, yes... thanks for the early warning.

I've wanted to improve this function before but had a mental blockage on
the page size difference. Looking at it with fresh eyes I think we
can make it clearer:

+static bool mlx5e_hw_gro_skb_has_enough_space(struct sk_buff *skb,
+                                             u16 data_bcnt, u32 page_size)
+{
+      int nr_frags = skb_shinfo(skb)->nr_frags;
+
+      if (nr_frags + DIV_ROUND_UP(data_bcnt, page_size) > MAX_SKB_FRAGS)
+              return false;
+
+      return skb->len + data_bcnt <= GRO_LEGACY_MAX_SIZE;
+}

Maybe we can squeeze more out of the last frag page, but one too many
extra checks would need to be added because SHAMPO might have moved on
to a new page.

Thanks,
Dragos
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.