User Details
- User Since
- Jan 22 2015, 5:22 AM (318 w, 26 m)
Thu, Feb 18
This will cause a HUGE performance impact! sbspace() is called often and
twiddling the extra locks is not useful. You are just looking (reading) two
variables or even one variable in the sbused case. You do not need a lock for this!
If we put the wrap
#ifdef TCPHPTS
Wed, Feb 17
Thu, Feb 4
Thu, Jan 28
So Hans:
Wed, Jan 27
Lets go ahead and not put the netflix_stats directive in front of the sysctl's.
Turns out we already had these defined if RATELIMIT is defined so lets
just add the two new ones.
Looks like I forgot to make sure we get the counters properly initialized in tcp_subr.c opps.
Take out the mlx bits so that Hans can commit them separately
Why are you removing the NOP Pad chunks? IP options *must* be a multiple of 4 which is what the pad does, taking
it out is going to make the options incorrect I would think??
Thats fine if you want to do it that way but note that this patch adds the new
function if_next_snd_tag() to if_var.h. You won't be able to add that function unless
we commit this one (without the mlx changes) first.
Tue, Jan 26
Jan 14 2021
Dec 13 2020
Dec 3 2020
Not exactly the best, but I think it fixes the immediate problem. From a long term perspective we may want to
look for a better solution :)
Nov 17 2020
Nov 9 2020
Oct 22 2020
Oct 8 2020
Sep 25 2020
Sep 9 2020
Sep 1 2020
Fix the typo's in the comment that Michael pointed out!
Aug 25 2020
Aug 24 2020
Aug 21 2020
Aug 18 2020
Aug 13 2020
Aug 10 2020
Jul 31 2020
First of all the tricky thing to remember about inp locks is that
Jul 16 2020
Jul 8 2020
Jun 23 2020
Opps used the wrong goto label...
Looks like BBR has the same issue, and we need to strip trailing emacs presents too :)
Jun 18 2020
Jun 16 2020
Jun 12 2020
Jun 8 2020
Jun 4 2020
I don't mind you tracking t_rtseq here, but please do not change the idle reduction in rack. I will go dig
up the right variable and change this to use that. Your are welcome to maintain t_rtseq but please don't change
the rack behavior here.
Jun 3 2020
It would not be EAGAIN/EBUSY since you can't do it again and expect it to succeed. I think
EINVAL is ok here.
May 29 2020
Ok turns out skyzaller has found yet another crash having to do with TFO for all three stacks. Lets update
the patch to fix that too.
May 25 2020
Has discussed on the transport call, I will be updating these to have a uint64_t and a nano-second basis for the values (including t_starttime I think since this
is what you compare these against) :)
May 21 2020
May 20 2020
I don't think that holding just the delta is what you really want. You want to be able
to tell when the first byte came in and the first byte went out. The delta only gives
one a partial view of what happened. And we are not living in 1984 where 64k of
memory is a lot. Four bytes to get more detailed information is I think worth it.
May 19 2020
Note that we don't want to commit these for a while since skyzaller uses these addresses but it
is something we should do.
Hmm I somehow got the wrong patch here.
May 18 2020
Yeah the spelling error check is rather dumb :)
May 15 2020
We should not ever do GP measurements until we are established
One little other niggle that I noticed, we should not do a goto again if the SYN bit is set ...
And even yet another issue thanks to skyzaller in bbr.. the rc_lost when doing TCP-FO was incorrect in rxt timers.
Let's also fix the accounting panic that skyzaller is finding here too. When we are in a front
state and have a SYN outstanding that should count in the ctf_outstanding size. Also if
we have sent a FIN same thing.