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

Jakub Kicinski <[email protected]> Mon, 3 Aug 2026 18:06:31 -0700
Newsgroups gmane.linux.drivers.rdma,gmane.linux.network,gmane.linux.kernel
Message-ID <[email protected]>
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.

> 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?
-- 
pw-bot: cr