- User Since
- Jun 2 2015, 9:23 PM (444 w, 2 d)
Thu, Nov 9
Thank you for asking, but I didn't actually do the last update. @jasone did it, but had to revert it. I simply un-reverted his work.
Oct 9 2023
Sep 19 2023
Aug 1 2023
Jul 28 2023
- remove DT_CLOSE_HANG, which never happens on FreeBSD
Jul 26 2023
Jul 25 2023
- rebase onto D41173; store flags in dt_proc
Jul 24 2023
- fix comment style
What do you think, @markj?
Jul 21 2023
Jul 20 2023
Jul 12 2023
The DTrace test suite had fewer failures with this change. They were not fixed by this change; they're just unreliable.
Jul 11 2023
- wordsmith comment
Jul 10 2023
Jul 7 2023
This needs a change in etc/mtree/BSD.tests.dist and perhaps ObsoleteFiles.inc.
Jun 1 2023
Thank you both for the feedback. I like the idea of using OpenBSD as an upstream, but that would take a lot more time than I have right now. (Most or all of my FreeBSD time is on Dell's clock.)
May 31 2023
May 30 2023
I think the best approach would be to import through the vendor branch and put it in contrib/cron, and altering the makefiles to contrib/cron instead. The vendor branch provides a better degree of maintainability.
May 24 2023
May 23 2023
Apr 14 2023
Apr 4 2023
please add the CID to the commit message
(unless this is not from Coverity Scan's FreeBSD report)
Mar 30 2023
It's not clear to me whether this is actually possible or just theoretical.
Mar 29 2023
Feb 21 2023
Feb 14 2023
Common practice for attributing the submitter with git is:
Dec 26 2022
Nov 17 2022
Nov 11 2022
@asomers What do you think?
Nov 9 2022
Nov 4 2022
- Fix the tests so they actually pass
Upload the whole diff.
- Don't use log_must in cleanup.
- Invert the test for dump devices in lieu of atf_expect_fail.
Nov 3 2022
Sep 8 2022
Sep 7 2022
Aug 24 2022
Aug 23 2022
Aug 22 2022
Would someone kindly make D35635 and D35636 public, now that they're committed?
Aug 19 2022
@markj Do the tests with largepagesize even make sense when superpages are disabled? I suppose not, but they're also harmless.
Jul 18 2022
define a way to limit mbuf cluster allocations to n in a code section
Why is this necessary? Why can't we let the driver allocate all available mbufs?
Because we want to avoid a situation where we exhaust all of our preallocated mbufs to fill populate a single ring. That's the reason we preallocate as much as we do today.
How do multi-queue NICs behave when some rx rings are empty? If a packet arrives on an empty rx ring, does the packet get dropped, or does it get queued to a different rx ring?
I've always assumed that the packet would get dropped if the ring to which it's steered doesn't have any available buffer space. That might not be true for all devices, but I wouldn't want to rely on that.
I like your plan overall. I'm not intimately familiar with the network drivers, so I can't comment on that aspect.