Re: [PATCH net-next V2 09/13] net/mlx5e: psp: Add an rx_decap steering table

On 8/4/26 4:35 AM, Tariq Toukan wrote:
> From: Cosmin Ratiu <[email protected]>
> 
> Introduce an additional steering table for PSP transport mode
> decapsulation, containing:
> - one rule per supported PSP version which does:
>    - transport mode decap (removes UDP+PSP headers and PSP trailer)
>      - recomputes iph->tot_len
>      - recomputes IP checksum
>      - reparses packet headers
>    - copy SPI into reg_b (which ends up as cqe.ft_metadata)
>    - set a decap marker and the PSP version in the flow_tag, so the RX
>      handler can make sense of the packet
> - default drop rule for unsupported PSP versions (per PSP spec).
> 
> Packets are forwarded to the previously added rx table, where:
> - one rule forwards UDP traffic to the UDP default destination.
> - default rule forwards traffic to the TTC table.
> 
> The reason is to avoid steering loops. If packets were to be injected
> into the TTC directly after rx_decap, it may be possible to create a
> steering loop with RX packets of the form IP|UDP|PSP|UDP|PSP...
> The rx flow table guarantees that packets go through PSP steering at
> most once.
> 
> The steering mode is saved in a new field 'fs.decap_enabled'.
> Updating the mode is done through accel_psp_fs_rx_reconfigure(), which
> creates the decap steering table if needed and possible. It then uses an
> atomic rule update to redirect traffic to the new table.
> This is now invoked with decap_wanted == false.
> The intention is for failures creating the new table to not block feature
> reconfig. A message is logged when table creation failed and PSP for HW
> GRO will not work in that case.
> Nothing happens on HW without the ability to decapsulate PSP transport.
> 
> An upcoming patch will add dynamic reconfiguration of PSP steering based
> on HW GRO.
> 
> Signed-off-by: Cosmin Ratiu <[email protected]>
> Reviewed-by: Dragos Tatulea <[email protected]>
> Signed-off-by: Tariq Toukan <[email protected]>
Cosmin, can you TAL at 
https://lore.kernel.org/all/0d72c5b2-6d4c-40d4-8cbe-8cd95d61a230-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org/ 
and let me know if this is an issue or not? I see the patch looks the 
same, but wasn't sure if you didn't see my message or if it is a false 
positive.