quoted

I agree that some of the result types (e.g., ENOMEM, END_SEQ_ERROR)
may be redundant or unlikely in practice. If we focus only on the most
critical cases, would the following subset be more acceptable?
- TCP_RETRANS_FAIL_QUEUED (packet stuck in host/driver queue)
- TCP_RETRANS_FAIL_ZERO_WINDOW (receiver window closed)
- TCP_RETRANS_FAIL_ROUTE (routing issues)
- TCP_RETRANS_FAIL_DEFAULT (catch-all for unexpected failures)

Isn't it enough to add the retval to the tracepoint?
All the cases we care about already have meaningful and distinct error
codes.

Hi Jakub,
I agree that using existing error codes (retval) in
could be a simpler and more maintainable approach.

Instead of introducing new TCP_RETRANS_* enums, I’ll directly
pass the retval to the tracepoint in patch v5.