[PATCH net-next 0/3] Single MSS length in UDP GSO_PARTIAL

[PATCH net-next 0/3] Single MSS length in UDP GSO_PARTIAL

[Gal Pressman]

This series addresses an inconsistency in how UDP GSO_PARTIAL handles
the UDP header length field.

Currently, when GSO_PARTIAL segmentation is used, the UDP header length
contains the large MSS size, requiring drivers to manually adjust it
before transmitting. This is inconsistent with how tunnel GSO_PARTIAL
handles outer headers in UDP tunnels, where the length is set to the
single segment size.

This was originally suggested by Alexander Duyck back in 2018:
https://lore.kernel.org/netdev/CAKgT0UcdnUWgr3KQ=RnLKigokkiUuYefmL-ePpDvJOBNpKScFA@mail.gmail.com/

The first patch fixes the core UDP offload code to set the UDP length
field to the single segment size (gso_size + UDP header) instead of the
large MSS size. This provides hardware with a proper template length
value for final segmentation.

The subsequent patches remove the now redundant UDP header length
adjustments from the mlx5e and aquantia drivers, as the core code now
handles this correctly.
I couldn't find any other drivers that support UDP GSO_PARTIAL; idpf
supports UDP segmentation, but it does not use GSO_PARTIAL.

Gal Pressman (3):
  udp: gso: Use single MSS length in UDP header for GSO_PARTIAL
  net/mlx5e: Remove redundant UDP length adjustment with GSO_PARTIAL
  net: aquantia: Remove redundant UDP length adjustment with GSO_PARTIAL

 drivers/net/ethernet/aquantia/atlantic/aq_nic.c |  3 ---
 .../mellanox/mlx5/core/en_accel/en_accel.h      | 17 -----------------
 net/ipv4/udp_offload.c                          |  6 ++++--
 3 files changed, 4 insertions(+), 22 deletions(-)

-- 
2.40.1

[PATCH net-next 1/3] udp: gso: Use single MSS length in UDP header for GSO_PARTIAL

[Gal Pressman]

In GSO_PARTIAL segmentation, set the UDP length field to the single
segment size (gso_size + UDP header) instead of the large MSS size.
This provides hardware with a template length value for final
segmentation, similar to how tunnel GSO_PARTIAL handles outer headers
in UDP tunnels.

This will remove the need to manually adjust the UDP header length in
the drivers, as can be seen in subsequent patches.

This was suggested by Alex in 2018:
https://lore.kernel.org/netdev/CAKgT0UcdnUWgr3KQ=RnLKigokkiUuYefmL-ePpDvJOBNpKScFA@mail.gmail.com/

Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Gal Pressman <gal@nvidia.com>
---
 net/ipv4/udp_offload.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 19d0b5b09ffa..89e0b48b60ae 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -483,11 +483,11 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
 	struct sock *sk = gso_skb->sk;
 	unsigned int sum_truesize = 0;
 	struct sk_buff *segs, *seg;
+	__be16 newlen, msslen;
 	struct udphdr *uh;
 	unsigned int mss;
 	bool copy_dtor;
 	__sum16 check;
-	__be16 newlen;
 	int ret = 0;
 
 	mss = skb_shinfo(gso_skb)->gso_size;
@@ -555,6 +555,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
 		return segs;
 	}
 
+	msslen = htons(sizeof(*uh) + mss);
+
 	/* GSO partial and frag_list segmentation only requires splitting
 	 * the frame into an MSS multiple and possibly a remainder, both
 	 * cases return a GSO skb. So update the mss now.
@@ -584,7 +586,7 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
 		if (!seg->next)
 			break;
 
-		uh->len = newlen;
+		uh->len = msslen;
 		uh->check = check;
 
 		if (seg->ip_summed == CHECKSUM_PARTIAL)
-- 
2.40.1

[PATCH net-next 2/3] net/mlx5e: Remove redundant UDP length adjustment with GSO_PARTIAL

[Gal Pressman]

GSO_PARTIAL now takes care of updating the UDP header length,
mlx5e_udp_gso_handle_tx_skb() is redundant, remove it.

Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Gal Pressman <gal@nvidia.com>
---
 .../mellanox/mlx5/core/en_accel/en_accel.h      | 17 -----------------
 1 file changed, 17 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/en_accel.h b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/en_accel.h
index 8bef99e8367e..b526b3898c22 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/en_accel.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/en_accel.h
@@ -100,20 +100,6 @@ static inline bool mlx5_geneve_tx_allowed(struct mlx5_core_dev *mdev)
 
 #endif /* CONFIG_GENEVE */
 
-static inline void
-mlx5e_udp_gso_handle_tx_skb(struct sk_buff *skb)
-{
-	int payload_len = skb_shinfo(skb)->gso_size + sizeof(struct udphdr);
-	struct udphdr *udphdr;
-
-	if (skb->encapsulation)
-		udphdr = (struct udphdr *)skb_inner_transport_header(skb);
-	else
-		udphdr = udp_hdr(skb);
-
-	udphdr->len = htons(payload_len);
-}
-
 struct mlx5e_accel_tx_state {
 #ifdef CONFIG_MLX5_EN_TLS
 	struct mlx5e_accel_tx_tls_state tls;
@@ -131,9 +117,6 @@ static inline bool mlx5e_accel_tx_begin(struct net_device *dev,
 					struct sk_buff *skb,
 					struct mlx5e_accel_tx_state *state)
 {
-	if (skb_is_gso(skb) && skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4)
-		mlx5e_udp_gso_handle_tx_skb(skb);
-
 #ifdef CONFIG_MLX5_EN_TLS
 	/* May send WQEs. */
 	if (tls_is_skb_tx_device_offloaded(skb))
-- 
2.40.1

[PATCH net-next 3/3] net: aquantia: Remove redundant UDP length adjustment with GSO_PARTIAL

[Gal Pressman]

GSO_PARTIAL now takes care of updating the UDP header length, remove the
redundant assignment in aq_nic_map_skb().

Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Gal Pressman <gal@nvidia.com>
---
 drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
index b24eaa5283fa..ef9447810071 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
@@ -701,9 +701,6 @@ unsigned int aq_nic_map_skb(struct aq_nic_s *self, struct sk_buff *skb,
 		} else if (l4proto == IPPROTO_UDP) {
 			dx_buff->is_gso_udp = 1U;
 			dx_buff->len_l4 = sizeof(struct udphdr);
-			/* UDP GSO Hardware does not replace packet length. */
-			udp_hdr(skb)->len = htons(dx_buff->mss +
-						  dx_buff->len_l4);
 		} else {
 			WARN_ONCE(true, "Bad GSO mode");
 			goto exit;
-- 
2.40.1

Re: [PATCH net-next 1/3] udp: gso: Use single MSS length in UDP header for GSO_PARTIAL

[Willem de Bruijn]

Gal Pressman wrote:
> In GSO_PARTIAL segmentation, set the UDP length field to the single
> segment size (gso_size + UDP header) instead of the large MSS size.
> This provides hardware with a template length value for final
> segmentation, similar to how tunnel GSO_PARTIAL handles outer headers
> in UDP tunnels.
> 
> This will remove the need to manually adjust the UDP header length in
> the drivers, as can be seen in subsequent patches.
> 
> This was suggested by Alex in 2018:
> https://lore.kernel.org/netdev/CAKgT0UcdnUWgr3KQ=RnLKigokkiUuYefmL-ePpDvJOBNpKScFA@mail.gmail.com/
> 
> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
> Signed-off-by: Gal Pressman <gal@nvidia.com>

Reviewed-by: Willem de Bruijn <willemb@google.com>

This only affects the udp header value when using GSO_PARTIAL, and
these are the only two drivers that adversize USO using GSO_PARTIAL.

> ---
>  net/ipv4/udp_offload.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 19d0b5b09ffa..89e0b48b60ae 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -483,11 +483,11 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>  	struct sock *sk = gso_skb->sk;
>  	unsigned int sum_truesize = 0;
>  	struct sk_buff *segs, *seg;
> +	__be16 newlen, msslen;
>  	struct udphdr *uh;
>  	unsigned int mss;
>  	bool copy_dtor;
>  	__sum16 check;
> -	__be16 newlen;
>  	int ret = 0;
>  
>  	mss = skb_shinfo(gso_skb)->gso_size;
> @@ -555,6 +555,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>  		return segs;
>  	}
>  
> +	msslen = htons(sizeof(*uh) + mss);
> +
>  	/* GSO partial and frag_list segmentation only requires splitting
>  	 * the frame into an MSS multiple and possibly a remainder, both
>  	 * cases return a GSO skb. So update the mss now.
> @@ -584,7 +586,7 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>  		if (!seg->next)
>  			break;
>  
> -		uh->len = newlen;
> +		uh->len = msslen;
>  		uh->check = check;
>  
>  		if (seg->ip_summed == CHECKSUM_PARTIAL)
> -- 
> 2.40.1
> 

Re: [PATCH net-next 2/3] net/mlx5e: Remove redundant UDP length adjustment with GSO_PARTIAL

[Tariq Toukan]

On 25/01/2026 14:16, Gal Pressman wrote:
> GSO_PARTIAL now takes care of updating the UDP header length,
> mlx5e_udp_gso_handle_tx_skb() is redundant, remove it.
> 
> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
> Signed-off-by: Gal Pressman <gal@nvidia.com>
> ---
>   .../mellanox/mlx5/core/en_accel/en_accel.h      | 17 -----------------
>   1 file changed, 17 deletions(-)
> 

Reviewed-by: Tariq Toukan <tariqt@nvidia.com>

Re: [PATCH net-next 0/3] Single MSS length in UDP GSO_PARTIAL

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Sun, 25 Jan 2026 14:16:46 +0200 you wrote:
> This series addresses an inconsistency in how UDP GSO_PARTIAL handles
> the UDP header length field.
> 
> Currently, when GSO_PARTIAL segmentation is used, the UDP header length
> contains the large MSS size, requiring drivers to manually adjust it
> before transmitting. This is inconsistent with how tunnel GSO_PARTIAL
> handles outer headers in UDP tunnels, where the length is set to the
> single segment size.
> 
> [...]

Here is the summary with links:
  - [net-next,1/3] udp: gso: Use single MSS length in UDP header for GSO_PARTIAL
    https://git.kernel.org/netdev/net-next/c/b10b446ce7ad
  - [net-next,2/3] net/mlx5e: Remove redundant UDP length adjustment with GSO_PARTIAL
    https://git.kernel.org/netdev/net-next/c/8d2eda97f464
  - [net-next,3/3] net: aquantia: Remove redundant UDP length adjustment with GSO_PARTIAL
    https://git.kernel.org/netdev/net-next/c/5b4015ad833c

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH net-next 1/3] udp: gso: Use single MSS length in UDP header for GSO_PARTIAL

[Alice Mikityanska]

On Mon, Jan 26, 2026, at 19:53, Willem de Bruijn wrote:
> Gal Pressman wrote:
>> In GSO_PARTIAL segmentation, set the UDP length field to the single
>> segment size (gso_size + UDP header) instead of the large MSS size.
>> This provides hardware with a template length value for final
>> segmentation, similar to how tunnel GSO_PARTIAL handles outer headers
>> in UDP tunnels.
>> 
>> This will remove the need to manually adjust the UDP header length in
>> the drivers, as can be seen in subsequent patches.
>> 
>> This was suggested by Alex in 2018:
>> https://lore.kernel.org/netdev/CAKgT0UcdnUWgr3KQ=RnLKigokkiUuYefmL-ePpDvJOBNpKScFA@mail.gmail.com/
>> 
>> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
>> Signed-off-by: Gal Pressman <gal@nvidia.com>
>
> Reviewed-by: Willem de Bruijn <willemb@google.com>
>
> This only affects the udp header value when using GSO_PARTIAL, and
> these are the only two drivers that adversize USO using GSO_PARTIAL.

I stumbled upon this patch when I was rebasing my stuff and saw a
(trivial) conflict. I've got a couple of questions on this change, and
I'd be glad if you could clarify it for me.

>> ---
>>  net/ipv4/udp_offload.c | 6 ++++--
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>> 
>> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
>> index 19d0b5b09ffa..89e0b48b60ae 100644
>> --- a/net/ipv4/udp_offload.c
>> +++ b/net/ipv4/udp_offload.c
>> @@ -483,11 +483,11 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>>  	struct sock *sk = gso_skb->sk;
>>  	unsigned int sum_truesize = 0;
>>  	struct sk_buff *segs, *seg;
>> +	__be16 newlen, msslen;
>>  	struct udphdr *uh;
>>  	unsigned int mss;
>>  	bool copy_dtor;
>>  	__sum16 check;
>> -	__be16 newlen;
>>  	int ret = 0;
>>  
>>  	mss = skb_shinfo(gso_skb)->gso_size;
>> @@ -555,6 +555,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>>  		return segs;
>>  	}
>>  
>> +	msslen = htons(sizeof(*uh) + mss);
>> +
>>  	/* GSO partial and frag_list segmentation only requires splitting
>>  	 * the frame into an MSS multiple and possibly a remainder, both
>>  	 * cases return a GSO skb. So update the mss now.

What about the frag_list case? The comment says it would be a GSO SKB
too (as I understand frag_list, it would be a linked list of SKBs
forming one single packet). Is it appropriate to set UDP len = MSS in
this case too? I'm not sure which code reads UDP len afterwards, I
couldn't find any, so maybe its value doesn't matter at all (except for
hardware, which this patch aims for).

Is it possible that this GSO_PARTIAL or frag_list packet shows up in
tcpdump with UDP len set like this? E.g., if the GSO_PARTIAL
segmentation happens before entering a veth pipe, and tcpdump listens on
the other end? If so, tcpdump could fail to parse such a packet.

I haven't tried to reproduce any of these yet; I decided to ask first
because you have more context. I'll appreciate if you can give me a clue
whether my concerns are valid or not.

Other than that, I think the patch could be made simpler, if you just
drop mss *= gso_segs below, and stick to newlen, which would be equal to
msslen (now unneeded), and newlen and mss are not used anywhere else.
I'll include this simplification in my next series, if you don't mind.

>> @@ -584,7 +586,7 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>>  		if (!seg->next)
>>  			break;
>>  
>> -		uh->len = newlen;
>> +		uh->len = msslen;
>>  		uh->check = check;
>>  
>>  		if (seg->ip_summed == CHECKSUM_PARTIAL)
>> -- 
>> 2.40.1
>>

Re: [PATCH net-next 1/3] udp: gso: Use single MSS length in UDP header for GSO_PARTIAL

[Gal Pressman]

Hello Alice,

On 03/02/2026 14:20, Alice Mikityanska wrote:
>>> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
>>> index 19d0b5b09ffa..89e0b48b60ae 100644
>>> --- a/net/ipv4/udp_offload.c
>>> +++ b/net/ipv4/udp_offload.c
>>> @@ -483,11 +483,11 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>>>  	struct sock *sk = gso_skb->sk;
>>>  	unsigned int sum_truesize = 0;
>>>  	struct sk_buff *segs, *seg;
>>> +	__be16 newlen, msslen;
>>>  	struct udphdr *uh;
>>>  	unsigned int mss;
>>>  	bool copy_dtor;
>>>  	__sum16 check;
>>> -	__be16 newlen;
>>>  	int ret = 0;
>>>  
>>>  	mss = skb_shinfo(gso_skb)->gso_size;
>>> @@ -555,6 +555,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>>>  		return segs;
>>>  	}
>>>  
>>> +	msslen = htons(sizeof(*uh) + mss);
>>> +
>>>  	/* GSO partial and frag_list segmentation only requires splitting
>>>  	 * the frame into an MSS multiple and possibly a remainder, both
>>>  	 * cases return a GSO skb. So update the mss now.
> 
> What about the frag_list case? The comment says it would be a GSO SKB
> too (as I understand frag_list, it would be a linked list of SKBs
> forming one single packet). Is it appropriate to set UDP len = MSS in
> this case too? I'm not sure which code reads UDP len afterwards, I
> couldn't find any, so maybe its value doesn't matter at all (except for
> hardware, which this patch aims for).

The behavior should be the same, the structure of the skbs the packet
originated from shouldn't affect this change.

> 
> Is it possible that this GSO_PARTIAL or frag_list packet shows up in
> tcpdump with UDP len set like this? E.g., if the GSO_PARTIAL
> segmentation happens before entering a veth pipe, and tcpdump listens on
> the other end? If so, tcpdump could fail to parse such a packet.

You will see a large packet with a single MSS value in tcpdump, and
that's consistent with the behavior we have for UDP tunnels.
tcpdump parses the packet without any issues.

> 
> I haven't tried to reproduce any of these yet; I decided to ask first
> because you have more context. I'll appreciate if you can give me a clue
> whether my concerns are valid or not.
> 
> Other than that, I think the patch could be made simpler, if you just
> drop mss *= gso_segs below, and stick to newlen, which would be equal to
> msslen (now unneeded), and newlen and mss are not used anywhere else.
> I'll include this simplification in my next series, if you don't mind.

Feel free :).

Re: [PATCH net-next 1/3] udp: gso: Use single MSS length in UDP header for GSO_PARTIAL

[Alice Mikityanska]

On Tue, Feb 3, 2026, at 15:51, Gal Pressman wrote:
> Hello Alice,
>
> On 03/02/2026 14:20, Alice Mikityanska wrote:
>>>> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
>>>> index 19d0b5b09ffa..89e0b48b60ae 100644
>>>> --- a/net/ipv4/udp_offload.c
>>>> +++ b/net/ipv4/udp_offload.c
>>>> @@ -483,11 +483,11 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>>>>  	struct sock *sk = gso_skb->sk;
>>>>  	unsigned int sum_truesize = 0;
>>>>  	struct sk_buff *segs, *seg;
>>>> +	__be16 newlen, msslen;
>>>>  	struct udphdr *uh;
>>>>  	unsigned int mss;
>>>>  	bool copy_dtor;
>>>>  	__sum16 check;
>>>> -	__be16 newlen;
>>>>  	int ret = 0;
>>>>  
>>>>  	mss = skb_shinfo(gso_skb)->gso_size;
>>>> @@ -555,6 +555,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>>>>  		return segs;
>>>>  	}
>>>>  
>>>> +	msslen = htons(sizeof(*uh) + mss);
>>>> +
>>>>  	/* GSO partial and frag_list segmentation only requires splitting
>>>>  	 * the frame into an MSS multiple and possibly a remainder, both
>>>>  	 * cases return a GSO skb. So update the mss now.
>> 
>> What about the frag_list case? The comment says it would be a GSO SKB
>> too (as I understand frag_list, it would be a linked list of SKBs
>> forming one single packet). Is it appropriate to set UDP len = MSS in
>> this case too? I'm not sure which code reads UDP len afterwards, I
>> couldn't find any, so maybe its value doesn't matter at all (except for
>> hardware, which this patch aims for).
>
> The behavior should be the same, the structure of the skbs the packet
> originated from shouldn't affect this change.
>
>> 
>> Is it possible that this GSO_PARTIAL or frag_list packet shows up in
>> tcpdump with UDP len set like this? E.g., if the GSO_PARTIAL
>> segmentation happens before entering a veth pipe, and tcpdump listens on
>> the other end? If so, tcpdump could fail to parse such a packet.
>
> You will see a large packet with a single MSS value in tcpdump, and
> that's consistent with the behavior we have for UDP tunnels.
> tcpdump parses the packet without any issues.

Yeah, just checked tcpdump: it shows the full payload, regardless of UDP
length and IP length in the headers. Sounds good to me, thanks for the
clarifications!

>> 
>> I haven't tried to reproduce any of these yet; I decided to ask first
>> because you have more context. I'll appreciate if you can give me a clue
>> whether my concerns are valid or not.
>> 
>> Other than that, I think the patch could be made simpler, if you just
>> drop mss *= gso_segs below, and stick to newlen, which would be equal to
>> msslen (now unneeded), and newlen and mss are not used anywhere else.
>> I'll include this simplification in my next series, if you don't mind.
>
> Feel free :).