- User Since
- Jun 22 2015, 5:21 PM (243 w, 1 d)
I'd prefer the check be moved inside _iflib_assert(), but that's just a nit.
Thu, Feb 13
Wed, Feb 5
What we really care about is not re-ordering the load so that we ensure it happens prior to the loop. So I think you want an atomic with acquire semantics:
"the operation must have completed before any subsequent load or store (by program order) is performed"
Mon, Feb 3
To expand on this, the issue is that interrupt handlers are removed via intr_event_execute_handlers() when IH_DEAD is set. The thread removing the intr is woken up, and he calls intr_event_update(). When this happens, the ie_hflags are cleared and re-built from all the remaining handlers sharing the event. When the last IH_NET handler is removed, the IH_NET flag will be cleared from ih_hflags (or ie_hflags may still be being rebuilt in a different context), and the ithread_execute_handlers() may return with ie_hflags missing IH_NET. So we can end up in a scenario where IH_NET was present before calling ithread_execute_handlers, and is not present at its return, meaning we must cache the need for epoch locally.
Sat, Feb 1
Mon, Jan 27
Fri, Jan 24
I like the idea of using a different ether_input() for epoch and non-epoch safe drivers to get the tests out of the critical path. However, this is a minor optimization at best, as branch predictors are really good these days on modern CPUs.
Wed, Jan 22
As we discussed in slack, I'm not a huge fan of fixing things with a callout. If the hardware was amenable, I'd much rather leave the ring partially stocked and drop new packets until we were able to allocate mbufs again. However, based on the findings you reported with igb (it wanting a full rx ring to generate interrupts), I'm afraid that might require too much work from hardware drivers. And I'd prefer a fix to a real problem, even if its not something I personally find appealing, to leaving a real bug unfixed and having machines become unreachable.
Mon, Jan 20
Jan 18 2020
Dec 29 2019
Why are there multiple reviews? The other one still appears to be open (https://reviews.freebsd.org/D18856)
Dec 22 2019
There is code which is clearly FreeBSD specific that needs to be converted to comply with style(9).
Dec 17 2019
Nov 18 2019
Nov 15 2019
Nov 7 2019
This fixes GPFs for me when using hwpmc on AMD Rome. The GPFs were triggered out of MSR writes in the amd hwpmc interrupt handler.
Nov 4 2019
Nov 1 2019
This was fixed in r353483, however the wrong differential was tagged in that commit, so this differential was never closed.
Oct 31 2019
Thanks for fixing this. The NULL canaries were left over from when iflib had a separate code path which avoided busdma. When I removed this codepath, I neglected to remove those canaries.
Oct 25 2019
Oct 24 2019
Oct 23 2019
Works fine running on a Netflix cache.
Oct 22 2019
Oct 10 2019
I just looked for a short time.. more comments later..
Oct 9 2019
Oct 8 2019
Yes, I meant adding a KASSERT or at least a comment.
I like this a lot. Note that I only looked at mxge and a few iflib drivers.
Oct 7 2019
Oct 6 2019
Oct 3 2019
Oct 1 2019
Moved PORTREVISION down a line to fix portlint complaint as pointed out by jhb
Sep 29 2019
Sep 28 2019
In my tests of UDP transmit using N copies of netperf on a 14c/28t Xeon E5-2697 v3 (haswell) using a 40Gbe ixl, I see nearly a 100% performance improvement (eg, double the packet rate) as compared to using mp_ring. In fact, for a single-threaded test the packet rate is 4x what it is for mp_ring with tx-abdicate enabled.
Sep 27 2019
Applied suggested changes prior to committing.
Re-submit diff with -U999999 for full context.
Updated the port to handle TLS 1.3
Applied suggested changes in what I'm about to commit.
Sep 26 2019
- I've taken linimon's changes from bugzilla
- I've hooked the port to the Makefile in the parent
Updated to address feedback from Hans:
- add comment that record_type must be first in the union
- added a constant for the 1.3 GCM iv len and checked it where we check it for 1.2
I tested this, and it performed well and worked fine.
Sep 25 2019
Sep 20 2019
Would it make sense then to assert that the link is down?
I'm not sure, but I think the only way this can happen is when the link is down. Is that the caee here?
Sep 17 2019
Uncrappy is nice. But if we've got lock contention, it would be nice to know why.
Sep 16 2019
Sep 14 2019
Sep 13 2019
- Fixed line wrap issues pointed out by igor
Address bz's concerns:
- Shorten lines in man page
- Make numa_domain consistently uint8_t
- simplify logic in places
- fix some style errors