Updated the diff to fix some corner cases and to better handle compile and testing in user space.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Thu, Apr 25
Mon, Apr 22
Thu, Apr 18
Why are you removing the data after close checks in BBR and Rack. This is not related to getting a FIN (where you may
still be open). The point of that is so that if we have closed after dumping data into the SB, and then the peer sends in
a request (not realizing we have closed yet) to NOT send a RST until after all the data is through. This was useful for
NF since often times Nginx will close() a connection after filling the N requests and finishing dumping data into the sb.
It say has 1Meg in the buffer when it does close().
Fri, Apr 5
Sun, Mar 31
Thu, Mar 28
Mar 27 2024
Add Drew's read_frequently compiler directive.
Mar 26 2024
Update to Gleb and I's agreed upon reduction at the if in system.h
In D44420#1015031, @glebius wrote:My bad, didn't understood proposed change. Of course if pointer stays stable since module load, there is no race.
Mar 25 2024
In D44420#1014931, @glebius wrote:In D44420#1014587, @rrs wrote:Why not just use
if (hpts_that_need_softclock > 0)
tcp_hpts_softclock()\?
But that would create the same race you mentioned above, wouldn't it? IMHO, using function pointer variable is the way to go and it potentially has a chance to get reduced to fewer instructions if compiler gets smarter.
Mar 23 2024
Another issue we will need to address is multiple hpts threads trying to set the tcp_hpts_softclock pointer. One can envision
a case where you have one that is just lowering it to zero, and so goes into the "set" to NULL block. And another thread that
is going from 0 -> 1 and so goes into the set to function block.
Why not just use
In D44420#1013898, @glebius wrote:Why can't we just clear and set the function pointer itself? That would reduce impact on userret() down to just one instruction.
Mar 21 2024
I do believe the extern is not needed here since systm.h is included.
Adopt Drew's optimization suggestion and reverted back the sysctl Michael pointed out since the arg is unused (and here I thought
all these years it was the default).
Mar 20 2024
Adopt Michael's suggestion to re-use one of the available bits for the flag.
Mar 19 2024
Updated to use an atomic instead of the u64_counter as Gleb suggests.
and yeah Drew we could add a block with sysctl
I can easily change to an atomic.. I did not realize the fetch was expensive :)
Mar 15 2024
Mar 12 2024
Mar 11 2024
Mar 7 2024
Mar 1 2024
Add in the additional MPASS as Gleb suggested.
Good catch Gleb, I missed the hpts.c changes.. I will update it :=)
Feb 29 2024
So in testing I found a slight bug in that we were on the connect() side setting up the PCM max seg to
early. This means we end up with 10 x 512 not 10 x mss. Lets fix it so just like the listening side things get
deferred until we have gotten to the established state.
The hpts change is now in https://reviews.freebsd.org/D44157
This separates out the hpts fix. Will add that as a new review after I drop this in. I have
tested the combined hpts fix and this with the current head and everything works as
expected :)
I still need to re-test this after the last sync I did.. will do that and then split out the hpts change and update the diff before landing..
Feb 28 2024
Feb 26 2024
Ok update to after the sync. Also I forgot to add in the inherit calls in the syncache and the tcp_usr_attach
Feb 20 2024
In D43986#1003519, @rrs wrote:In D43986#1003451, @tuexen wrote:Did you try git add tcp_pcm.c? Please note that this week is stabilization week, meaning only bug fixes should go in...
No I did not, but once I do that will it show up in the diff?
I will give it a try and see.
In D43986#1003451, @tuexen wrote:Did you try git add tcp_pcm.c? Please note that this week is stabilization week, meaning only bug fixes should go in...
Fix a bug I found in testing (and I think Gleb just pointed out)
Jan 24 2024
Dec 7 2023
Dec 4 2023
One comment, Hans had a hand in restructuring the code a while ago too :)
Nov 30 2023
Nov 27 2023
Nov 16 2023
Oct 5 2023
Oct 4 2023
Sep 7 2023
Jul 13 2023
Jun 28 2023
Jun 27 2023
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.
Jun 26 2023
Jun 9 2023
Jun 2 2023
May 24 2023
May 23 2023
May 19 2023
May 18 2023
Apr 21 2023
Apr 20 2023
Why if 0x10000 is not used would it matter?