Re: Question: net/mlx5e kTLS TX TIS reuse vs in-flight WQEs

[Tariq Toukan <tariqt@nvidia.com>]

On 10/11/2026 1:21, Rishikesh Jethwani wrote:
 > Thanks. I've now reviewed the seven-patch RFC [1]. The held-skb,
 > full-resync and pass-through changes cover the points I raised. I've
 > replied on patches 7 and 4 with two remaining holes in the one-SQ
 > guarantee: the selection-time ownership transfer, and the PTP SQs in
 > the drain.

Thanks for the review. Agreed on both, replied there.

 > The DEK question is still open: once all old-key WQEs have retired, may
 > the old DEK be destroyed or returned for reuse while an idle TIS still
 > names it? This needs to cover both standalone DEKs and pooled IDs reused
 > by another connection. A flushed replacement need not have installed
 > the new key, and deletion can return the still-bound TIS to its pool.
 > The resync fix restores the context on its next use, but does not by
 > itself establish that releasing the old DEK before then is safe.
 >
 > Please keep that HW/FW answer explicit. Until it is settled, I cannot
 > treat a flush/close alone as sufficient to release a still-named DEK;
 > the conservative alternative is to retain the possible bindings until
 > a successful replacement or TIS destruction, including through pooling.

Double checking. Will update.

 > Agreed. I'll replace v18's live TX del+add with the new callback and
 > implement mlx5e_ktls_rekey_tx() on the revised fixes.

Sounds good.

 > The delayed decrypted-clone case remains a separate core follow-up.

[...]

 > I'll Cc you when I post it.

Thanks, please do.

 > I do need patch 7, with the selection-time fix from my reply to it, as
 > a rekey dependency. Patches 1-6 alone do not cover egress skbedit or a
 > cached queue overwritten by another device on the route. A fenced
 > replacement on SQ B cannot order itself against old-key WQEs still on
 > SQ A. Keeping patch 7 in net-next is fine; I'll base rekey on it as
 > well as the net fixes.

Right, I missed those cases. Rekey depends on patch 7 too, and v2 of
the RFC will carry the selection-time fix.

Thanks,
Tariq