Re: [PATCH v4 net 2/3] net: mlx5e: fix CWR handling in drivers to preserve ACE signal

[Paolo Abeni <pabeni@redhat.com>]

On 4/23/26 4:19 PM, Dragos Tatulea wrote:
> On 23.04.26 09:30, Paolo Abeni wrote:
> [...]
>>> ---
>>>  drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
>>> index 5b60aa47c75b..9b1c80079532 100644
>>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
>>> @@ -1180,7 +1180,7 @@ static void mlx5e_shampo_update_ipv4_tcp_hdr(struct mlx5e_rq *rq, struct iphdr *
>>>  	skb->csum_offset = offsetof(struct tcphdr, check);
>>>  
>>>  	if (tcp->cwr)
>>> -		skb_shinfo(skb)->gso_type |= SKB_GSO_TCP_ECN;
>>> +		skb_shinfo(skb)->gso_type |= SKB_GSO_TCP_ACCECN;
>>
>> Here there is an open question for nVidia:
>>
> Sorry for missing this question in v3.
> 
>> Is the above enough or will later segmentation lead to the wrong
>> results? I think/guess the firmware is (still) aggregating the wire
>> frames using the ECN schema, i.e. the first wire packet has CWR == 1,
>> the later CWR==0.
>>
> For mlx5 HW-GRO a packet with the CWR flag will flush the previous GRO session
> and will not start a GRO session for this packet (napi_gro_receive() will be
> called on this single segment skb).
> 
> So this change won't impact the current GRO behavior from the mlx5 driver/hw side.

OK, thanks!

For my education: doesn't the above also means that mlx5 will never
build GSO packets with CWR set (and so the above statement should never
be reached)?

/P