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

On Tue, 2026-08-04 at 13:19 -0400, Daniel Zahka wrote:
> 
> 
> 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/[email protected]/
>  
> 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.

Apologies for this, I was on vacation and couldn't reply. And I think I
misled Tariq into thinking this wasn't a real issue, so he posted the
series again (Apologies, Tariq). As noted in V1, this will be addressed
in V3.

Cosmin.