> > > > > > > > -/* > > > > - * tcp event with arguments sk and skb > > > > - * > > > > - * Note: this class requires a valid sk pointer; while skb pointer > > > > could > > > > - * be NULL. > > > > - */ > > > > -DECLARE_EVENT_CLASS(tcp_event_sk_skb, > > > > +#define TCP_RETRANSMIT_QUIT_REASON \ > > > > + ENUM(TCP_RETRANS_ERR_DEFAULT, "retransmit > > > > terminate unexpectedly") \ > > > > + ENUM(TCP_RETRANS_SUCCESS, "retransmit > > > > successfully") \ > > > > + ENUM(TCP_RETRANS_IN_HOST_QUEUE, "packet still > > > > queued in driver") \ > > > > + ENUM(TCP_RETRANS_END_SEQ_ERROR, "invalid end > > > > sequence") \ > > > > + ENUM(TCP_RETRANS_TRIM_HEAD_NOMEM, "trim head no > > > > memory") \ > > > > + ENUM(TCP_RETRANS_UNCLONE_NOMEM, "skb unclone > > > > keeptruesize no memory") \ > > > > + ENUM(TCP_RETRANS_FRAG_NOMEM, "fragment no > > > > memory") \ > > > > > > Do we really need 3 + 1 different 'NOMEMORY' status ? > > > > Yes, different "NOMEM" status pinpoint exact failure stages in packet > > retransmission, > > which helps distinguish which process triggered it. Beneficia > > ENOMEM is ENOMEM. Honestly I fail to see why it matters. > > If this was the case, we would have thousands of different ENOMEM errnos.
Hi Eric, Thanks for reviewing the patch and your valid feedback – I agree with your point that excessive ENOMEM granularity could create unnecessary redundancy in the kernel. My initial intent was to differentiate allocation failures in TCP retransmission (TRIM_HEAD, UNCLONE, FRAG) to pinpoint exact failure points during debugging, since these errors occur at distinct stages with different stack contexts. However, I recognize that ENOMEM itself sufficiently conveys the core issue. We will consolidate these into a unified TCP_RETRANS_NOMEM in v4 of the patch. Appreciate your time and expertise!
