- User Since
- Jan 22 2015, 5:22 AM (279 w, 6 d)
It would not be EAGAIN/EBUSY since you can't do it again and expect it to succeed. I think
EINVAL is ok here.
Fri, May 29
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.
Mon, May 25
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) :)
Thu, May 21
Wed, May 20
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.
Tue, May 19
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.
Mon, May 18
Yeah the spelling error check is rather dumb :)
Fri, May 15
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.
Thu, May 14
Tue, May 12
Thu, May 7
Mon, May 4
gets rid of some emacs trailing ws
Apr 28 2020
Follow Michaels suggestion and go 2016 - 2020 in the copyright instead of 2016 - 20
Even though there are no plans to add ECN to BBRv1, lets go ahead
and add back the uint8_t iptos value since you never know we might
circle back and do this plus we also want to remain somewhat consistent
between BBR and Rack
I would suggest leaving the iptos changes in. It does not
harm in BBR and someday we will be doing BBRv2 and in
that we will do ECN.. so best to leave it in place I think.
Lets go ahead and add the new function to return that we don't do PRUS_OOB as long as we are in fixing things.
Update to fix inadvertent overwrite of error and the name of the option function change per Michael's comment
Apr 27 2020
Now that D24575 is in lets take it a step further and provide the hooks so
we can ask a transport (optionally) if they support various PRU_XXX flags.
If they don't provide a function then they "support all" PRU_XXX flags.
Now that I know MSG_OOB is out of the picture make the appropriate update.
Address all of Michael's first set of comments.
Address all of Michael's comments
Apr 26 2020
Apr 10 2020
Mar 12 2020
Mar 9 2020
Mar 8 2020
Feb 27 2020
Feb 26 2020
Feb 18 2020
Update comments and name of the mss function per the comments in the review.
Feb 12 2020
Address Hans comments, also fix the issue I had
when I back things out (the net epoch macro should have
been in the source).. also add just a few more comments and
fix a spelling error in one.
Jan 24 2020
Jan 8 2020
Jan 6 2020