So this is a subtle bug I have found in cubic. If you compile a number of options into the kernel (accounting and tracking) then
all of the kernel code "knows" the proper offset of t_rttupdatecnt however cubic does not see the options (and htcp too) and thus
will look for the count in the wrong place seeing 0. Which then means it never builds an MIN RTT which then means it
always hangs in slowstart.
Details
Details
- Reviewers
tuexen rscheff - Group Reviewers
transport - Commits
- rG96eb0d90cd75: tcp: With the right options in the kernel cc_cubic stays in slowstart always.
Rebuild the kernel with the new tcpcb layout and test to make sure cubic comes out of SS.
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Why do the CUBIC and HTCP cc modules see a different struct tcpcb than the reset of the code?
Comment Actions
Wouldn't it be better to have opt_inet.h included explicitly in tcp_var.h - since that is where those compile time options appear to be defined? Then any kernel module should have the same visibility to the optional variables. I feel moving the variables around and relying on them to stay in a particular order is brittle...
Comment Actions
struct tcpcb depends on TCP_ACCOUNTING, TCP_REQUEST_TRK, TCPPCAP, and TCP_HHOOK. It seems that all these are defined in opt_global.h, except TCP_ACCOUNTING, which is defined in opt_inet.h. This does not look consistent to me. So I think the best might be to move TCP_ACCOUNTING from opt_inet.h to opt_global.h? @rrs Does that also solve the issue?
Comment Actions
After looking at this and thinking on it changing the structure is the *wrong* approach since it leaves a landmine in place
that can get someone if they don't include opt_inet.h. The better choice is to make all things that ifdef in the tcppcb to
be in opt_global.h so that the entire kernel always knows what tcpcb looks like.