Re: [PATCH net] net/mlx5e: Add mutual exclusion between PSP and PTP TX port timestamping

[Carolina Jubran]

On 04/08/2026 4:06, Jakub Kicinski wrote:
> On Wed, 29 Jul 2026 09:51:37 +0300 Tariq Toukan wrote:
> > The WQE flow_table_metadata field is shared by multiple TX offloads:
> > IPsec, MACsec, PTP timestamping and PSP each write to it.
> >
> > Commit [1] resolved the conflicts between IPsec/MACsec and PTP
> > by shifting their markers to bits [8+], leaving PTP's 8-bit metadata
> > index in bits [7:0] without overlap.
> > But then PSP support was added in commit [2], which writes a 32-bit
> > keyid across all bits of flow_table_metadata. Unlike IPsec and MACsec,
> > PTP timestamping applies independently of encryption -- a PSP-encrypted
> > packet can also require a HW timestamp. When both write to the same
> > WQE, the values corrupt each other, leading to wrong PTP timestamp
> > tracking and potentially wrong PSP encryption keys.
> Is the concern about Tx? (please clarify)
> If so, Tx HW timestamps are never guaranteed, why can't we just
> skip timestamping for PSP packets? Only TCP supports PSP, and
> upstream TCP and HW timestamps are pretty much mutually exclusive.


Yes, this is about Tx

You are right. I missed that PSP is TCP only, so it never
selects ptpsq. Thanks for the clarification.

I'll drop this patch and I will revisit how to avoid a metadata
collision without adding overhead on the datapath.


Thanks!


> > Prevent the conflict at configuration time by blocking:
> > - Enabling TX-port-TS when PSP has active TX keys.
> > - Adding PSP TX keys when TX-port-TS is already enabled.
> Why catch PSP at the Tx key programming? PSP docs very explicitly
> require drivers to _not_ enable the feature by default. And tx
> keys can't be added if it's disabled. So it would make much more
> sense to catch the enable / config callback of PSP?