- User Since
- Mar 1 2015, 6:19 PM (150 w, 1 d)
Sat, Jan 13
Wed, Jan 3
Tue, Jan 2
Mon, Jan 1
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?
Sun, Dec 31
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.
Mon, Dec 18
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.
Mar 18 2016
Fix user-level include of in_pcb.h
rt_gen_t was in an ifdef _KERNEL
Argh, I see what I did. I ended up with the wrong version of route.h in /usr/include.
Mar 14 2016
Update to match head, fix UDP/IPv4 locking
Move definitions to match movement in header files.
Feb 15 2016
OK, I missed the malloc/copy in if_ethersubr.c. So there isn't a problem with pointers to freed memory, but the L2 code still has the issue as the routing code with copying the pointers to/from the route structure.
Feb 9 2016
I'll respond to other parts soon. But I want to correct this:
Feb 7 2016
About L3 caching:
Jan 23 2016
This revision does several things:
Dec 13 2015
I haven't reviewed this as closely as I should. However, if I read this correctly, this is a new caching mechanism that:
Dec 8 2015
Randall: see also D4306 for another approach.
Dec 3 2015
Thanks, I think I understand your position better now. But you are objecting mostly to the current API and data structures, not against using them. What I mean is that the "struct route" *is* the existing mechanism to get and hold a reference to a rtentry. The rtentry is the existing entity that contains the exported information, and "private" management information, and includes a reference count and a bit (RTF_UP) to report invalidation of the route to the remaining references. (And the route structure did not change for radix; that the rtentry.) So, while you apparently want to replace the API and implementation, we should take full advantage of what's there now, unless/until something new arrives in head. The same points apply to the llentry.
Thanks for the pointer to your wiki page; I wasn't aware of that before now. It sounds like you have some interesting work in progress. However, I don't agree with your conclusion that caching the route and lle are "wrong" or "hacks". The interface to route and lle validation could be encapsulated, but ip*output need to look up routes and get the information, and it will always be faster to cache the value than to make a "fast" lookup.
Nov 29 2015
Nov 28 2015
Apr 3 2015
Following up on Glebius' comment: I think this interface is fine for the short term, including MFC. I think it is quite reasonable to come up with an improved interface, both ioctl and KPI, for 11. I don't think more bits for existing fields is a big enough motivation; I think the interface needs a fair amount of thought and rework. I'm willing to assist in this, but we also need input from driver authors.
Mar 30 2015
You are right, it doesn't work. I switched to IFM_X. See ftp.karels.net/outgoing/if_media.h.
This now requires re-review; reviewers, could you take a look?
Mar 25 2015
I meant that _X should be undefed, not that it was. I forgot to do it. If there are no other changes, could you add that? Thanks.
Hmm, looks like if_media.h isn't right. Eric, did you apply the new patch to the previous version? It was meant to apply to the base version. It is currently only using one extra bit for extended type. Check the whole file, it should be right.
Yes, I pulled in all the types from the latest in D2056 except VFAST.
Mar 24 2015
A few notes on the last update:
Mar 15 2015
I was experimenting with this version, and noticed that VFAST is not in the extended range. If I move it there, I can no longer select it for vtnet. The problem is that the IFM_SUBTYPE_ETHERNET_DESCRIPTIONS array encodes the non-shifted value (in my case, 50), and that doesn't match the shifted value in the if_media list. So it appears that this patch does not work for selecting extended media types.
Mar 14 2015
Yes, as I said earlier, libpcap and net-snmp use IFM_SUBTYPE. ifconfig certainly uses it as well. I don't know how many ports use it, or other network monitoring software (including commercial software).
IFM_SUBTYPE uses IFM_TMASK, and it's a macro. Thus, anything that uses IFM_SUBTYPE uses IFM_TMASK. It's precisely because of MFCs that I want good binary compatibility. Only ifconfig and drivers using new subtypes need to use the new ioctl, and any ports that want to be able to detect the new subtypes.
Mar 13 2015
net-snmp definitely uses IFM_SUBTYPE. libpcap uses it as well, although it only checks for AUTO. I would think these would be sufficient to justify reasonable binary compatibility.
Don't forget IFM_SUBTYPE(); not even ifconfig uses TMASK directly.
I don't have a specific example, although SNMP comes to mind as a candidate. However, you seem to be assuming that anything from ports will be recompiled, and that is not a reasonable assumption for embedded systems and appliances (such as I work on).
Binary compatibility is not just for old ifconfig binaries. IIRC, there were on the order of 60 users of SIOCGIFMEDIA in our tree, which included things like SNMP. Doing 2 ioctls in ifconfig is not a big deal.
I like the idea of using bits from the Ethernet-specific options field, so as to get more than one additional bit. I'm not sure it is wise to use all of them; perhaps one can be kept (still allows 511 variants).