- User Since
- Jan 22 2015, 5:22 AM (178 w, 18 h)
Tue, Jun 19
Mon, Jun 18
Thu, Jun 14
Tue, Jun 12
Turns out after looking at Larry's last core and contemplating it a bit if it
would have succeeded (which it did not) we would have crashed anyway.
This is because the SYN got included in the send_map and we would have
tried to trim 14 instead of the 13 that bytes in the socketbuffer. Fixing that
means the send_map cannot start at snd_una for the TFO case. This means
a bit more special code needs also to be added to the SYN_SENT case then
so you end up incrementing snd_una when you move to established and that
way when you call the ack processing code all will be well :)
So this is weird we look like we sent a TFO and then hit a retransmit.. but somehow
the TFO flags was removed so we did not set len == 0 on having a SYN retransmitted.
Mon, Jun 11
Get the vnet set much earlier and all the right bits around earlier too.
Thu, Jun 7
A couple of configs I use:
Wed, May 23
May 22 2018
Looking closely at this and thinking about tcp_hpts.c, if I grok this correctly
this should all integrate ok. Assuming that someone calls inp_pcbfree() on
something that is in hpts, even if the epoch_call happens, the inpcb won't
be freed until the hpts's main loop see the INP_FREED flag and does
its in_pcbrele_wlocked() call at which time the INP will finally get destroyed.
May 9 2018
Apr 26 2018
Apr 25 2018
Yeah I had those in there in our version so I could
validate the range in amd64 with the DMAP_VM but for
some reason those don't work in head anymore.. Forgot
to purge the headers :)
Apr 20 2018
One of the nice things that having a module which is the default stack does is that
changes of any type can be made in the module. Then you can test those changes
before applying the changes to the main stack. That makes it rather nice that
one can try before we buy changes to the included stack. We have used that
fairly effectively at NF on deploying new versions of things (not the default stack but rack)
Yes I gained about 1/2Gbps of added performance in my tests.
As to VIMAGE who really uses that? No one I know of. Considering
the use of it (or lack there of) I saw of no real reason to have it
in the first-cache-line. Of course the other question is how
often does one use the back-pointer to the parent vnet.
Apr 19 2018
Apr 18 2018
Apr 12 2018
This adds the comments that Hiren had asked for and I even
add a comment block at the top of tcp_hpts.c to talk about usage
(not a design document but some hints on use). Note also Hiren
that the hpts system can be used by the default freebsd stack. Our
internal NF default stack actually has some of these hooks in it as
well so we can enable "pacing" with various options.
Thanks for looking at this. Note that rack is not in yet because it lacks this commit. This is the
first commit in the steps to get rack that we use at NF for 99% of traffic into the FreeBSD core code.
These have to go in first :)
Apr 11 2018
After jtl and I chatted I finally understand his request (just a bit thick I guess) so
now I wrap up his final comment.
This address Gleb and Jonathans comments and also now passes a build universe
Apr 10 2018
Apr 9 2018
Apr 6 2018
Aug 9 2017
Mar 17 2017
In general I love this change with my few nits. Note I have a major restructure coming
to inpcb and tcpcb that this helps pave the way for. Basically I have used vtune to
cache-line optimize tcp-output to get its cache line usage down.
Oct 20 2016
Oct 14 2016
I think that a grand idea :)
Oct 10 2016
Oct 7 2016
Looks like a great idea :-)
Sep 8 2016
Aug 26 2016
Aug 18 2016
Aug 16 2016
This gets Jtl's changes in.. I also move the init function down to the
end of the tcb init.. otherwise its possible a init() function may find
that some state init'd later is not what it expects (though it still
has to allow for this in the inp.. lets try to make it easier on the init's built)
Jul 27 2016
Jul 26 2016
Looks good Drew :)
Jul 21 2016
Jul 19 2016
I really need to learn how to type :-)
Turns out when tp is returned NULL by the drop/close that means
it also nicely released the INP_WLOCK. We need to re-acqurire the lock
in that case so we can drop our inp reference.
Originally I had started working on this before Gleb decided to take over and clean it up. I
had fixed the three issues I saw:
- Principle - the start of a new timer was not rejected (like it is for sync drain) for async-drain.
- A three way leak in the callout start
- An incorrect return on some cases with async_drain and tcp.
Fix it so we don't leak inp's.. the tcp_close() can return NULL in tp, this
would mean we would not do the reference count release. Instead use
Jul 18 2016
Jul 6 2016
This addresses Jonathan's Nits.. However after reading the man page I can't see how one would
discuss the finer points of changing stacks (there is no mention of it that I can see in the current
man page). Jonathan perhaps you can, as we say in the IETF, send text :-)
Jul 5 2016
I had not noticed your man page updates.. I will spin around and add the new handoff function to the man page on the next pass (with my comments).
Should there not be a check to the experimental setting to allow a IW of 10?
These look fine and familiar ;-)
I am fine with these changes, however it does *not* mean the fix I sent you does
not also need to be applied. I.e. if an async_drain is running (just like when a drain is running)
we need to return failure and not start the timeout again.
Jun 11 2016
Updated with change we discussed and also two bugs.. when you
do the lookup, a refcnt is incremented so if you were to stay
on the same one you need to release the refcnt (it gets to 2 in that case). And
also in one error path we need to do that (before the lookup was later).
Jun 9 2016
May 25 2016
If Drew says it works I am happy with it as well :-)
May 17 2016
May 11 2016
Is TCPTV_DELACK (hz/25) 40 ms, or is it 40 ms only when HZ is 1000?
May 10 2016
Apr 28 2016
It would be worth checking the assembly output.. if it truly inlines it then
it should probably only do one compare.. but worth checking...
Apr 18 2016
This fixes Michael's nits
Apr 13 2016
jch: Thanks for running your torture tests.. I did not take out the flags you added though I
am not sure we need them anymore.. what do you think?
As a testing update to this, I have this running in a netflix storage cache last
night. I did add a netstats counter in addition to this whenever we incremented
the async-drain counter (tt_draincnt)
Apr 12 2016
Please test this now for V6 I think I have it right.. and I have also cleaned up a few
space changes so I think its in good shape.