- User Since
- Mar 1 2015, 6:19 PM (198 w, 2 d)
Sat, Dec 8
Nov 16 2018
Oct 30 2018
Sep 22 2018
Sep 19 2018
It would be good to see if the crashes stop before committing this, but it looks right to me.
Sep 6 2018
Sep 3 2018
Sep 1 2018
I believe I understand the issue with route caching. in6_selectroute_fib checks for loopback,and substitutes the interface with the local address. ip6_output doesn't need to know that interface, it should just skip the scope check in that case. I'll email a possible kernel patch to Andrey and Harti.
Aug 28 2018
You are right, inp_route6 would be better. I'm sure I copied and pasted, then didn't make as many changes as I should have. I will happily approve a review to make that change if you test that it compiles :-).
May 17 2018
Looks good to me. I could go either way on the blank line.
Mar 10 2018
Mar 9 2018
Thanks for catching the typo.
Mar 8 2018
Feb 28 2018
Feb 27 2018
Feb 10 2018
I agree with the change as well; the regression seems to have happened when the code was refactored and the "add" and "change" code became joined.
Jan 23 2018
Jan 22 2018
Got it. I didn't realize it, but Phabricator lists the reviews in reverse order, so that's the order I looked at them.
Jan 20 2018
I just realized that this is necessary when the L3 gateway changes. The L3 cache doesn't need to be invalidated, but L2 does. A comment to this effect would be helpful.
Could this use the new invalidate macro?
Was there a place where only L3 was invalidated?
Why is this necessary, or desirable? If a route that is cached is modified, that doesn't invalidate it. It should still be the best route if it was before.
Jan 13 2018
Jan 3 2018
Jan 2 2018
Jan 1 2018
A list of ioctl names didn't seem very useful to me, so I extracted the information from the header file.
IIRC, there are ten of these ioctls, although I didn't add any. I thought I'd correct the obvious out-of-date statement, but wasn't sure I could correctly document all of those added over time. Suggestions?
Dec 31 2017
Rod, perhaps you have never needed this functionality; but have you ever had a system hang? Along the same lines, there are probably about 1000 bits of code that you haven't needed in the kernel; should we add options to remove each of them? This way lies madness. There are two hardclock routines; which are you using? Should we ifdef out the other?
Sorry, my last comment was responding to imp@; it crossed with the comment from rgrimes.
Thanks. About loadable hardware watchdogs: that should work if they attach before watchdogd starts.
Dec 18 2017
Dec 9 2017
Nov 27 2017
Nov 25 2017
Fix macro usage, update text
Nov 24 2017
Nov 18 2017
Another attempt to clarify, flesh out example.
Nov 17 2017
Update Dd date
Sep 26 2017
Sep 24 2017
I hadn't noticed this snippet of code before. It was definitely wrong.
Aug 29 2017
Commited in https://reviews.freebsd.org/rS316065
Apr 22 2017
Apr 10 2017
Mar 27 2017
Mar 25 2017
Mar 20 2017
Dec 31 2016
I think the change is a step in the right direction. Certainly, "ifconfig xxN down" followed by an implicit UP should not cause any change to the routing table. Does anyone know why the "down" is removing the route? That seems wrong to me.
Seems fine to me; will let someone else approve.
Sep 21 2016
Aug 24 2016
Aug 22 2016
btw, the second chunk (first after include) is new since original version.
This patch has been tested by Mike Andrews, who will continue monitoring. I've asked Peter if he can test.
Aug 20 2016
Aug 14 2016
Aug 11 2016
Aug 3 2016
Jul 24 2016
I'm looking into the account issue.
Jul 22 2016
I'm not sure my acceptance "counts" using mike-karels.net; if you add karels@, I can re-approve.
Looks good to me. This will only update one connection, but there is nothing wrong with that. We could receive a large number of redirects if there are a lot of connections using the same route. Another option would be to increment the route table revision if a redirect adds a new route, doing nothing if it changes a route. But this is quick and expedient. It should obviously be MFC'ed to 11.0.
Jul 19 2016
May 28 2016
Update to current HEAD; fix to work with flowtable
May 21 2016
Hello? Is anyone looking at this?
May 8 2016
Apr 27 2016
I disagree; congestion is congestion, not "congestion for everyone but me". I'd prefer to leave the cwnd change until it is replaced by something more modern.
Apr 21 2016
btw, I think the line to set the snd_cwnd should remain for now, until something replaces it. ENOBUFS signals local congestion.
Apr 16 2016
Setting a retransmission timer on an ACK makes no sense; I don't think tcp_output will send an ACK on a retransmission timeout.
I believe that the original code is wrong, and the change is not sufficient
to fix it. The retransmit timer should be running if and only if we have
sent data into the receive window and are awaiting an ACK. The persist
timer should be running if and only if the retransmit timer is not running,
and we have data to send that do not reasonably fit in the window. If we
get an ENOBUFS when sending data, we will already be running the retransmit
timer. If we drop an ACK on ENOBUFS, either we will receive more data and
attempt another ACK, or the sender will time out and resend data. Either
will get the connection started again. I believe lines 1552-1554 should
simply be deleted.
Mar 19 2016
This change does not affect forwarding, just TCP and UDP termination. It makes the most difference when TSO is not enabled.