On Thu, Oct 8, 2026 at 5:20 PM <[email protected]> wrote: > > From: Neil Ramaswamy <[email protected]> > > Hi Neal and Eric, > > Thanks for the detailed replies. Neal's approach is much cheaper than my > original patch on a few UML microbenchmarks that I ran. > > I'm not entirely sure I understand Eric's usage of "often" when he mentioned > the O(1) list splice, but the metrics that I've collected from my particular > repro seem to suggest that Neal and Yuchung's assumption about LOST but not > EVER_RETRANS segments holds in the cases I captured, so I'd be happy with that > approach.
Great! Thanks for checking those. > (One super nit on the runtime complexity of it: in the comment for > tcp_tsorted_relink_skb we say that it's O(1) amortized time, but I think it's > more that during partial undo all relink calls together traverse the RACK list > at most once.) Sure, OK. :-) > For Neal's fix, I also did write up a small packetdrill that shows that > segments > that are already retransmitted and then marked LOST are not added back to the > RACK list during partial undo, as intended. Happy to contribute that if useful > for explicitly documenting that this is behavior we are okay with. Sounds great. Please include that new test as another follow-on patch. I agree that test would be useful to document this behavior and ensure the expected things happen (and no bad things happen) in that case. > How would you like to move forward here? Do you want me to fold this into a v3 > patch with attribution tags or do you want to send a new patch yourself? Please feel free to send out a v3 patch with attribution tags. Thanks! neal
