[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46ae0b27-c9cd-45ea-a58f-a91238e8bf0b@intel.com>
Date: Fri, 22 Aug 2025 09:02:21 -0700
From: Tony Nguyen <anthony.l.nguyen@...el.com>
To: Eric Dumazet <edumazet@...gle.com>, "David S . Miller"
<davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>
CC: Simon Horman <horms@...nel.org>, <netdev@...r.kernel.org>,
<eric.dumazet@...il.com>, Przemek Kitszel <przemyslaw.kitszel@...el.com>,
Jacob Keller <jacob.e.keller@...el.com>, Madhu Chittim
<madhu.chittim@...el.com>, Pavan Kumar Linga <pavan.kumar.linga@...el.com>,
Joshua Hay <joshua.a.hay@...el.com>, Brian Vazquez <brianvv@...gle.com>,
Willem de Bruijn <willemb@...gle.com>, Andrew Lunn <andrew+netdev@...n.ch>
Subject: Re: [PATCH net-next] idpf: do not linearize big TSO packets
On 8/18/2025 12:59 PM, Eric Dumazet wrote:
> idpf has a limit on number of scatter-gather frags
> that can be used per segment.
>
> Currently, idpf_tx_start() checks if the limit is hit
> and forces a linearization of the whole packet.
>
> This requires high order allocations that can fail
> under memory pressure. A full size BIG-TCP packet
> would require order-7 alocation on x86_64 :/
>
> We can move the check earlier from idpf_features_check()
> for TSO packets, to force GSO in this case, removing the
> cost of a big copy.
>
> This means that a linearization will eventually happen
> with sizes smaller than one MSS.
>
> __idpf_chk_linearize() is renamed to idpf_chk_tso_segment()
> and moved to idpf_lib.c
>
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Cc: Tony Nguyen <anthony.l.nguyen@...el.com>
Acked-by: Tony Nguyen <anthony.l.nguyen@...el.com>
> Cc: Przemek Kitszel <przemyslaw.kitszel@...el.com>
> Cc: Jacob Keller <jacob.e.keller@...el.com>
> Cc: Madhu Chittim <madhu.chittim@...el.com>
> Cc: Pavan Kumar Linga <pavan.kumar.linga@...el.com>
> Cc: Joshua Hay <joshua.a.hay@...el.com>
> Cc: Brian Vazquez <brianvv@...gle.com>
> Cc: Willem de Bruijn <willemb@...gle.com>
> Cc: Andrew Lunn <andrew+netdev@...n.ch>
Powered by blists - more mailing lists