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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 24 2020
Some feedback:
Jan 22 2020
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.
Jan 20 2020
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.
In D19111#476197, @hselasky wrote:@gallatin: Network drivers can also use worker threads instead of IRQ's to process packets. Especially USB network devices.
In D21801#476448, @jhb wrote:Actually, we need to update the logic that populates the TLS header to stop writing the 8 byte nonce for GCM for 1.3 in ktls_seq? It probably doesn't hurt for it to stay, but it would be cleaner if we removed it. I've actually thought about reworking what we do anyway. The 8 byte nonce doesn't have to be the sequence number, it just has to be unique per record. OpenSSL picks a random 8 byte value and increments it. We could actually do the something similar and generate the TLS header always in ktls_frame(). We would generate an 8 byte random value that is saved in the TLS session when it is created and just increment it for each record that is framed. There's no requirement that the nonce's be monotonically increasing, etc. just unique per record. This would simplify ktls_seq() and would make the 1.3 vs 1.2 handling a bit clearer.
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.
In D21122#472928, @olivier wrote:
Sep 16 2019
Sep 14 2019
In D21636#471988, @kbowling wrote:This isn't worth much consternation but I do wonder if we can try to limit the proliferation of these sockopts. For instance, if you generalize the existing _LB to take a generic integer arg, would that and cpuset achieve the same effect (and generalize to however people want to use those numbered groups?)
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
Sep 11 2019
Sep 10 2019
Aug 30 2019
Aug 27 2019
In D21122#466175, @olivier wrote:Flamegraph:
Aug 23 2019
Aug 21 2019
Aug 18 2019
Aug 16 2019
In D21122#462385, @olivier wrote:On another hardware (Atom 4cores):
x inet4 forwarding of small packet size, bypass_mpring=0 in packets-per-second + inet4 forwarding of small packet size, bypass_mpring=1 in packets-per-second +--------------------------------------------------------------------------+ |+ + ++ + x x x x | | |______A__M____|| | |_______________A_____M________| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 4 927858.5 983285 971934 963752.88 24606.11 + 5 749042 872241 859294 839484.8 51106.313 Difference at 95.0% confidence -124268 +/- 66405 -12.8942% +/- 6.76603% (Student's t, pooled s = 41856.6)Bigger impact her: -12%
Aug 15 2019
Aug 2 2019
Jul 24 2019
Jul 23 2019
Oh, and in the documentation, it would be handy to note that BIOSes will sometimes disable this functionality and you may need to enable or disable certain common settings in the BIOS.
I just cherry picked this into my tree to try on some servers. As a *USER*, I have the following comments: