Mon, Oct 14
Sun, Oct 6
Sat, Sep 28
Well I am going to voice a different view. I do *not* see this as a nice cleanup. I see it
has a lessening of information.
Tue, Sep 24
Mon, Sep 23
Sep 20 2019
Sep 17 2019
This updates the patch set, the ktls.h information was incorrect. I also add the fixes
that Michael is doing on the Rack side to BBR as well (check for invalid length in non-tso case).
Sep 11 2019
Sep 10 2019
Sep 9 2019
I would like to see the Rack version of the code be identical to the tcp_input version.. i.e. it should check
Sep 6 2019
Sep 3 2019
First version was missing a (void) in the registration function.. opps
This adds a simple registration mechanism that stacks can use as they successfully register/deregister to
make the LRO code aware if any stack wants to use mbuf-queueing per Drew's suggestion.
Aug 26 2019
Aug 21 2019
Aug 15 2019
One more update, mainly comments but we also fix a couple of things
- The timestamp provided via the ctf common functions should be the real time not something from the mbuf, we let the transports look at those flags (which both BBR and the latest Rack do).
- We also for LRO add a gating of the number of acks (currently set to infinity) that can also cause a wakeup.
Aug 13 2019
The LRO patch was missing data and length limits for input processing via
MBUF_QUEUE methods. This update adds that and an elaborate set of
comments to the rack_bbr_common.c module describing in detail what
a transport designer using MBUF_QUEUEING needs to contemplate.
Aug 2 2019
Aug 1 2019
Jul 29 2019
Please validate the rack_bbr_common.c has (or does not have) the extra bit you added in the early part.
I plan on commiting this August 1st unless I hear screams.. its been pending since July 15th....
Jul 21 2019
Update to address Michael's comments about copyright (missing new magic declarations at the top) and
also address an issue where if we have an interface that marks it to "not supporting" we properly
disable the rate limiting for that interface and do not allow the user to enable it (since it does
not support it).
Jul 18 2019
Jul 16 2019
Jul 15 2019
Jul 14 2019
Jul 12 2019
Jul 11 2019
Jul 10 2019
Add in the hopeless exit to tcp_hpts and also get the corrected (with DSACK patch) rack_18q22p2
Update to include some fixes Michael and I have been working on in a slow slow machine as well
as bring the Rack stack up to the latest production (with some small changes to make it compile).
Jul 3 2019
And we can't loose the commented out opt_kern_tls until the kern tls hits the tree
It helps if one remembers to bring the changes of the .h file too ... opps
Address phabricator nits
In my detailed testing of hpts I found we are *not* doing the right thing as to calculating
the time for sleep. The code was starting at where the prev_slot was and moving
through counting the slots until it found a non-empty slot.
Jul 2 2019
So interestingly those includes are not needed.. not even sure the tls one is need (hwtls should be in the tree soon).. however more
interesting is why my freebsd head build works.. not sure why since it does not have hwtls in the mix.. need to go check whats going
on in my conf.
Jun 28 2019
Jun 5 2019
sorry wrong revision.. the trouble is in the DSACK commit which is r347382... thats what we are backing out of our sync... (off by
one error.. must be a programmer :-) )
There are for more problems then this. And its not explicitly with HPTS but it becomes the canary in the coal mine.
The basic problem is in r347381. This cause a huge slow down to the system at least with INVARIANTs. Hpts in
the form you are dealing with does handle wheel wrap well. We are backing out that change in our upstream
merge. And there will be changes I will be committing to fix wheel_wrap in hpts.
May 9 2019
Apr 10 2019
Apr 3 2019
Mar 27 2019
Mar 26 2019
Mar 23 2019
Mar 19 2019
Mar 18 2019
Mar 17 2019
Feb 21 2019
Feb 20 2019
Feb 19 2019
Feb 13 2019
Feb 11 2019
get the update in and fix the pesky extra line.
Feb 4 2019
Feb 1 2019
Update to hopefully get a better view and not have the stray line in the diff
Interesting my svn copy does not have that extra chunk.. let me re-update the diff and use -x -up
This updates the diff to Fix Hann's point on vlans, both the
vlan and lagg are now balanced.
Ahh good catch I did not know vlan had an allocator.. I will add it to the patch-set