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

[Carolina Jubran <cjubran@nvidia.com>]

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?