mlx5e kTLS RX: what do DECRYPTED and ERROR guarantee?

Hi Tariq,

My TLS 1.3 KeyUpdate series (v17 [1]; v18 in preparation) needs the
mlx5 RX guarantees below, particularly for the decrypt_failed patch
under discussion in [2]. Please identify supported devices/FW and cite
references where public documentation exists.

Tests used ConnectX-6 Dx, FW 22.46.3048, TLS 1.3 AES-128-GCM over IPv4.
The load sender used one write() per 16 KiB record with TCP_NODELAY.
Targeted cases included 622-byte records. F is the first new-key record.

Observed packet shapes:
  - F spans packets: DECRYPTED prefix, ERROR on the tag packet;
    transformed F payload, untouched following-record head.
  - F fits one packet: ERROR with transformed payload. If KeyUpdate
    shares that packet, its encrypted payload was transformed too.
  - Host drops the DECRYPTED prefix: pristine retransmitted head plus
    transformed ERROR tail.
  - Bad tag without rekey, 16 KiB or 622-byte record: ERROR with
    transformed payload; software authentication rejected the record.

The two small-record shapes and host-drop case each passed 4/4, with
correct data and offload reinstalled. Payload comparisons and CQE dumps
found no additional transformation discriminator. No tested ERROR case
left the failed payload untouched.

1. If every packet of a record is CQE_TLS_OFFLOAD_DECRYPTED, is its tag
   guaranteed verified? Can the final tag packet be marked DECRYPTED
   before verification succeeds? The stack skips software authentication
   for fully DECRYPTED records. Is ERROR only ever set on a packet
   containing a record end, or can a header-parse or length error
   produce ERROR on a packet without one? If a tag straddles packets,
   is ERROR on the final tag byte's packet? Tests did not split tags.

2. On ERROR, are encrypted payload bytes of all records through the
   failed record transformed, including preceding valid records in that
   packet? Are later bytes, headers, explicit IVs and tags unchanged?
   Can the failed payload instead remain as wire ciphertext? Does this
   depend on NO_OFFLOAD/AUTHENTICATION or SEARCHING, and what metadata
   distinguishes the cases?

3a. Can the old context transform anything after F, including later
    records in the same packet or speculative work?
3b. With F incomplete after loss, can hardware skip it and resume at a
    known later record boundary without confirmation, as described in
    tls-offload.rst?
3c. Can pending RESYNC requests, GET_PSV completions or resync parameter
    updates restart transformation after F? Are stale confirmations
    discarded or applied at the current position? Is there a distance
    limit?
3d. Does mid-record loss without KeyUpdate stop transformation without
    requesting resync, and what restarts it?

With KeyUpdate processing delayed, dropping the middle of 16 KiB F,
followed by a small L (separate or sharing F's tail packet), produced
no further transformation or resync until context replacement. With
an old-key header missing, a late confirmation for a later old-key
header after the device passed KeyUpdate produced no DECRYPTED/ERROR.
A control before KeyUpdate resumed transformation and failed on F.
All runs delivered data correctly.

4. Is re-add supported when next_record_tcp_sn is behind the stream,
   with rec_seq naming the record at that anchor? Given later traffic
   and a valid resync response, is SEARCHING/RESYNC recovery guaranteed,
   and how far behind may the anchor be? In the load run,
   all 90 rekeys resumed via resync with the stream 2.3-3.4 MB ahead;
   the first DECRYPTED completion was observed 6.4-9.3 ms after add.

5. After the re-add in Q4, while the tracker is still in START, are
   retransmits wholly below the anchor passed untouched as NOT_DECRYPTED
   without changing tracker/record number? For a straddling packet, are
   below-anchor bytes untouched and tracking begun at the anchor, or can
   old ciphertext cause false framing or loss of synchronization?

6. With basic/enhanced CQE compression, are TLS-status CQEs excluded,
   or do all packets sharing a title have the same TLS status?
   mlx5e_decompress_cqe() inherits that status from the title.

7. In mlx5e_ktls_del_rx(), after steering-rule deletion completes, can
   old-context packet DMA or CQEs still be posted? Does completion of
   the DESTROY_TIR command rule that out? Are old-context packets tied
   to the RQ selected before deletion, or can their destination change?
   Can later RSS/aRFS traffic use another RQ and be polled before
   pending old-context completions?

Please note any ConnectX-7 / BlueField-3 or firmware differences.

Thanks,
Rishikesh

[1] https://lore.kernel.org/netdev/20260917224355.2288021-1-rjethwani@purestorage.com/ (local)
[2] https://lore.kernel.org/netdev/20260917224355.2288021-11-rjethwani@purestorage.com/ (local)