In D47925#1095113, @glebius wrote:Later I'd probably bring the input and output to same KBI, so that both return same signedness error for unlocked return. But this requires a sweeping change over stacks, so later.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Thu, Dec 12
Thu, Dec 12
Wed, Dec 11
Wed, Dec 11
Ok after a detailed analysis:
Mon, Dec 9
Mon, Dec 9
Thu, Dec 5
Thu, Dec 5
rrs requested changes to D47925: tcp_hpts: refactor the per tcpcb call to either input/output method.
Wed, Dec 4
Wed, Dec 4
rrs added inline comments to D47925: tcp_hpts: refactor the per tcpcb call to either input/output method.
rrs added inline comments to D47925: tcp_hpts: refactor the per tcpcb call to either input/output method.
Mon, Nov 25
Mon, Nov 25
Mon, Nov 18
Mon, Nov 18
Nov 15 2024
Nov 15 2024
rrs committed rG12fc79619aca: Change the SOCKBUF_LOCK calls to use the more refined SOCK_XXXBUF_LOCK/UNLOCK. (authored by rrs).
Change the SOCKBUF_LOCK calls to use the more refined SOCK_XXXBUF_LOCK/UNLOCK.
I agree with Michael here, macros badly hide things.. which is their intention :)
Nov 13 2024
Nov 13 2024
rrs added reviewers for D47542: Change the SOCKBUF_LOCK calls to use the more refined SOCK_XXXBUF_LOCK/UNLOCK.: glebius, tuexen, rscheff.
Oct 23 2024
Oct 23 2024
Aug 20 2024
Aug 20 2024
Aug 9 2024
Aug 9 2024
Non-tested experimental code removal.
Aug 8 2024
Aug 8 2024
Fix what I thought I had fixed i.e. Unused_71 .. but for some reason I missed it ⭕
go through all the enum's and mark UNUSED those that are not used.
Aug 5 2024
Aug 5 2024
I am fine with this Drew, just went through and verified the departure code running earlier should have no impact...
Jul 30 2024
Jul 30 2024
Jul 26 2024
Jul 26 2024
This changes the enum, as discussed on a previous conf call to be "UNUSED" still taking the slot. I don't necessarily
agree with that but if everyone else wants it I am fine with it :)
Jun 27 2024
Jun 27 2024
Take out inadvertent space adds.
Jun 14 2024
Jun 14 2024
This gets rid of the defines mentioned by Michael in comments and as prescribed by Gleb on the last TCP conf call i.e.
we comment them out like in other code.
May 31 2024
May 31 2024
May 30 2024
May 30 2024
rcv-ack-finwait-1-ipv6 PASSED
rcv-fin-finwait-1-ipv4 PASSED
rcv-fin-finwait-1-ipv6 PASSED
rcv-fin-finwait-2-ipv4 PASSED
rcv-fin-finwait-2-ipv6 PASSED
rcv-ack-closing-ipv4 PASSED
rcv-ack-closing-ipv6 PASSED
rcv-ack-last-ack-ipv4 PASSED
rcv-ack-last-ack-ipv6 PASSED
rcv-ack-timewait-ipv4 PASSED
rcv-ack-timewait-ipv6 PASSED
rcv-fin-timewait-ipv4 PASSED
rcv-fin-timewait-ipv6 PASSED
rcv-syn-timewait-ipv4 PASSED
rcv-syn-timewait-ipv6 PASSED
Summary: Number of tests run: 881
Number of tests passed: 849 Number of tests failed (expected): 32 Number of tests failed (unexpected): 0 Number of tests timed out (expected): 0 Number of tests timed out (unexpected): 0 Number of tests skipped: 0
May 18 2024
May 18 2024
rrs committed rGea916b64125b: Remove TCP_SAD optional code now that the sack filter performs this function. (authored by rrs).
Remove TCP_SAD optional code now that the sack filter performs this function.
May 16 2024
May 16 2024
rrs requested review of D45216: Remove TCP_SAD optional code now that the sack filter performs this function..
May 11 2024
May 11 2024
Committed it: fce03f85c5bf
May 5 2024
May 5 2024
rrs committed rGfce03f85c5bf: TCP can be subject to Sack Attacks lets fix this issue. (authored by rrs).
TCP can be subject to Sack Attacks lets fix this issue.
May 4 2024
May 4 2024
May 3 2024
May 3 2024
Address all of Richards comments including the one I had to think about it was correct :)
Apr 30 2024
Apr 30 2024
One more update, need to use the tcp function call not t_maxseg - 12 to get the maxseg for filtering purposes
Add detailed comments so it is more clear what is going on inside sack_filter.h
One minor update my user space test did not show a new unused var that my kernel compile shows up. Fix that and
update the test information since I now validated the kernel version as well.
Apr 25 2024
Apr 25 2024
Updated the diff to fix some corner cases and to better handle compile and testing in user space.
Apr 22 2024
Apr 22 2024
Apr 18 2024
Apr 18 2024
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().
Apr 5 2024
Apr 5 2024
Mar 31 2024
Mar 31 2024
Mar 28 2024
Mar 28 2024
rrs committed rGb7b78c1c169d: Optimize HPTS so that little work is done until we have a hpts thread that is… (authored by rrs).
Optimize HPTS so that little work is done until we have a hpts thread that is…
Mar 27 2024
Mar 27 2024
rrs updated the diff for D44420: Optimize HPTS so that little work is done until we have a hpts thread that is over the connection threshold.
Add Drew's read_frequently compiler directive.
Mar 26 2024
Mar 26 2024
rrs updated the diff for D44420: Optimize HPTS so that little work is done until we have a hpts thread that is over the connection threshold.
Update to Gleb and I's agreed upon reduction at the if in system.h
rrs added a comment to D44420: Optimize HPTS so that little work is done until we have a hpts thread that is over the connection threshold.
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
Mar 25 2024
rrs added a comment to D44420: Optimize HPTS so that little work is done until we have a hpts thread that is over the connection threshold.
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
Mar 23 2024
rrs added a comment to D44420: Optimize HPTS so that little work is done until we have a hpts thread that is over the connection threshold.
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.
rrs added a comment to D44420: Optimize HPTS so that little work is done until we have a hpts thread that is over the connection threshold.
Why not just use
rrs added a comment to D44420: Optimize HPTS so that little work is done until we have a hpts thread that is over the connection threshold.
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
Mar 21 2024
rrs updated the diff for D44420: Optimize HPTS so that little work is done until we have a hpts thread that is over the connection threshold.
I do believe the extern is not needed here since systm.h is included.
rrs updated the diff for D44420: Optimize HPTS so that little work is done until we have a hpts thread that is over the connection threshold.
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
Mar 20 2024
rrs updated the diff for D44420: Optimize HPTS so that little work is done until we have a hpts thread that is over the connection threshold.
Adopt Michael's suggestion to re-use one of the available bits for the flag.
Mar 19 2024
Mar 19 2024
rrs updated the diff for D44420: Optimize HPTS so that little work is done until we have a hpts thread that is over the connection threshold.
Updated to use an atomic instead of the u64_counter as Gleb suggests.
rrs added a comment to D44420: Optimize HPTS so that little work is done until we have a hpts thread that is over the connection threshold.
and yeah Drew we could add a block with sysctl
rrs added a comment to D44420: Optimize HPTS so that little work is done until we have a hpts thread that is over the connection threshold.
I can easily change to an atomic.. I did not realize the fetch was expensive :)
Mar 15 2024
Mar 15 2024
Mar 12 2024
Mar 12 2024
rrs committed rGe18b97bd63a8: Update to bring the rack stack with all its fixes in. (authored by rrs).
Update to bring the rack stack with all its fixes in.
Mar 11 2024
Mar 11 2024
rrs committed rGf6d489f402c3: Update to bring the rack stack with all its fixes in. (authored by rrs).
Update to bring the rack stack with all its fixes in.
Mar 7 2024
Mar 7 2024
Mar 1 2024
Mar 1 2024
rrs committed rG638b5ae1c785: HTPS has actually three states not two so the macro needs to account for that. (authored by rrs).
HTPS has actually three states not two so the macro needs to account for that.
rrs updated the diff for D44157: HTPS has actually three states not two so the macro needs to account for that..
Add in the additional MPASS as Gleb suggested.
rrs added a comment to D44157: HTPS has actually three states not two so the macro needs to account for that..
Good catch Gleb, I missed the hpts.c changes.. I will update it :=)
Feb 29 2024
Feb 29 2024
rrs added inline comments to D44157: HTPS has actually three states not two so the macro needs to account for that..
rrs updated the summary of D44157: HTPS has actually three states not two so the macro needs to account for that..
rrs added inline comments to D44157: HTPS has actually three states not two so the macro needs to account for that..
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 28 2024
Feb 26 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