Page MenuHomeFreeBSD

tcp: Inconsistent use of hpts_calling flag
ClosedPublic

Authored by rrs on Apr 18 2023, 1:08 PM.
Tags
None
Referenced Files
F102656625: D39653.diff
Fri, Nov 15, 10:45 AM
F102612071: D39653.diff
Thu, Nov 14, 7:14 PM
Unknown Object (File)
Wed, Oct 16, 2:33 PM
Unknown Object (File)
Oct 15 2024, 7:25 AM
Unknown Object (File)
Oct 14 2024, 9:54 AM
Unknown Object (File)
Oct 13 2024, 1:55 AM
Unknown Object (File)
Oct 11 2024, 12:54 PM
Unknown Object (File)
Oct 10 2024, 7:24 AM
Subscribers

Details

Summary

Gleb has noticed there were some inconsistency's in the way the inp_hpts_calls flag was being used. One
such inconsistency results in a bug when we can't allocate enough sendmap entries to entertain a call to
rack_output().. basically a timer won't get started like it should. Also in cleaning this up I find that the
"no_output" side of input needs to be adjusted to make sure we don't try to re-pace too quickly outside
the hpts assurance of 250useconds.

Another thing here is we end up with duplicate calls to tcp_output() which we should not. If packets go
from hpts for processing the input side of tcp will call the output side of tcp on the last packet if it is needed.
This means that when that occurs a second call to tcp_output would be made that is not needed and if pacing
is going on may be harmful.

Lets fix all this and explicitly state the contract that hpts is making with transports that care about the
flag.

Test Plan

Make sure that pacing still works since this may be directly impacted by these changes.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

rrs requested review of this revision.Apr 18 2023, 1:08 PM

Almost forgot, when going through the compressed ack path we will need to possibly nuke the flag too if
output did not occur...

This revision is now accepted and ready to land.Apr 18 2023, 2:34 PM