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 | org.kernel.vger.linux-kernel,org.kernel.vger.linux-rdma,org.kernel.vger.netdev |
|---|---|
| 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