- User Since
- May 28 2014, 2:27 PM (445 w, 6 h)
- Zero t_precisions[which] in tcp_timer_enter(), by mav@
- Provide precision calculation in tcp_timer_next() per Alexander's suggestion.
- Save precisions from callout_when() and use them when scheduling.
- Use callout_when() to make sure that we are rounded down
- Don't use local variable named "ticks"
Mon, Dec 5
I see. The current code uses callout_reset_on() which has C_HARDCLOCK in the macro, that does this rounding down. Do I understand it correct that the "precision" argument to callout_reset_sbt_on() becomes pretty useless if we specify C_HARDLOCK?
Fri, Dec 2
I plan to push this change next week.
Fri, Nov 25
I got some profiling data when running without WITNESS and with patch that counts the loops. The machines were serving 10 - 100 Gbit/s, but as they are using RACK, they use TCP timers not as often as the default stack does. Some machines didn't detect any looping but most experienced very little looping:
Mon, Nov 21
Profiling data for longer period. Note that the kernel is with WITNESS, I believe this explains very long spin times. In a day or two I will have larger profiling data for a group of machines and without WITNESS.
# sysctl net.inet.tcp.timer_stop_loops net.inet.tcp.timer_stop_loops: 0 5 4 5 2 3 5 7 3 3 1 0 2 0 0 0 0 1 2 1 0 0 0 0 0 0 0 0 0 0 0 0 # uptime 5:12PM up 3 days, 7:58, 2 users, load averages: 9.67, 9.64, 9.86
- Rename the flag.
- Check absence of flag before setting.
Fri, Nov 18
Some profiling on how often and how long the looping happens. With this patch:
Add a handler for callout_stop() failure and a comment explaining what's going on.
Thu, Nov 17
Thu, Nov 10
Just a fractional micropercent optimization suggestion. First set the VNET context, then enter the epoch. Same at the end: first exit the epoch, then restore VNET pointer. The VNET context set on a thread for extra time doesn't have any negative impact. The epoch prolonged for extra time does.
Wed, Nov 9
Has been committed 9eb0e8326d0fe73ae947959c1df327238d3b2d53
Yes, you are right. It is impossible to create raceless self-freeing callout with two callouts embedded into the same structure. This revision superseded by D37321.
Tue, Nov 8
Note: this version will fire KASSERT at certain conditions, as it is incorrect. However, even with correct assert this version has potential use after free, that is hidden by the use of SMR memory for tcpcbs. Right now this revision is not targeted to cgit, it is posted just to share code.
Nov 4 2022
Nov 3 2022
I'm also putting that on tomorrows TCP talk agenda with tuexen, rscheff and others.
May I ask for more time? I just found out that the only reason the TIME_WAIT persists correctly with the current code is that callout_drain_async() doesn't really behave as it is documented. Even when it is able to stop callout immediately, it will leave it for a drain at the scheduled time. So, when I was doing the 9c3507f91987b7c8ce3b895a5ee46a1de6bc42f2 change, I was puzzled why I can safely remove all this TIME_WAIT handling from here, as it seems right, but is never executing. Now I realized why it happened so. I'm working towards standard callout KPI for the TCP timers and this will very likely almost revert 9c3507f91987b7c8ce3b895a5ee46a1de6bc42f2 back to original Robert's code. It could be that the TOE problem will go away or it could manifest itself in a different manner.
Nov 2 2022
Looking at 267334. IMHO, we should return the error for invalid message as close as possible to the userland. Don't let the invalid data travel this down.
Can we return unsigned value from ng_get_composite_len() instead?
Oct 31 2022
@jhb can you please share the actual panic message and trace with TOE? Also the suggested change is actually two different changes preventing call tp tcp_usr_disconnect() in TIME-WAIT. Is there two different panic paths?
Oct 29 2022
May I ask for time until Wednesday to think more about this? If it critical for further work on TOE it is fine to just commit as is.
Oct 26 2022
Oct 25 2022
I would prefer to understand and eliminate the scenario when we are calling disconnect on an already disconnected socket, instead of reintroducing this bandaid. Is there any way for me to reproduce it without Chelsio hardware?
Oct 24 2022
Oct 21 2022
This is how it gets through! I should also restore the KASSERT()s in rack/bbr, then.
Oct 19 2022
Was abandoned in favor of D23518
This legacy revision has some metadata legacy from subversion times. The arc tool fails on it. Will reopen this revision with git-arc.
More discussion on the suppression back when it was added: https://lists.freebsd.org/pipermail/freebsd-net/2004-December/006088.html