Gigabit PPPoE and Intel Drivers
-
Did a few more tests.
With em driver
net.isr.dispatch=deferred
700-800mbpsnet.isr.dispatch=direct
675-715
most of the tests seem around 700 give or take a fewWith igb
net.isr.dispatch=direct
500-600mbpsnet.isr.dispatch=deferred
650-700So net.isr.dispatch in both cases made a difference, but still shy of the 920 or so I should be pulling.
-
You can disable the Kernel PTI workaround for Meltdown in System > Advanced > Misc. You almost certainly don't need it anyway unless you are running virtual.
The IBRS workaround for Spectre may not be active anyway but you can disable that too with the loader tunable:
hw.ibrs_disable=1
https://wiki.freebsd.org/SpeculativeExecutionVulnerabilities
Steve
-
@stephenw10 said in Gigabit PPPoE and Intel Drivers:
You can disable the Kernel PTI workaround for Meltdown in System > Advanced > Misc. You almost certainly don't need it anyway unless you are running virtual.
That's not correct. You need to mitigate meltdown unless you are 100% confident that there is no need for privilege separation on a system. (E.g., if you have no reason to run a web service as something other than root, or run pre-auth ssh code as an unprivileged user, etc.) If you use privilege separation as a mitigation for other vulnerabilities (e.g., bug in web script, bug in ssh, etc.) then you need meltdown mitigation in order for the privilege separation to actually be meaningful. Other speculative execution bugs like L1TF-VMM (CVE-2018-3646) are specific to virtual machines.
-
@vamike that would only really apply if there's any ability to execute malicious code within the privilege separated processes right? If the router is locked down so only trusted individuals can to access it and there are no available vulnerablities (big IF I know) there's should be no way someone can take advantage of the vulnerablities.
I know there was some grumblings of a remote spectre like exposure but I don't know if that applies to routers.
-
@dopey said in Gigabit PPPoE and Intel Drivers:
@vamike that would only really apply if there's any ability to execute malicious code within the privilege separated processes right? If the router is locked down so only trusted individuals can to access it and there are no available vulnerablities (big IF I know) there's should be no way someone can take advantage of the vulnerablities.
Sure. Like any other mitigation, it's a risk based decision. OTOH, if you can be sure that you can lock things down and never have a vulnerability, why are you running a firewall at all?
-
Mmm, interesting. Some stuff I had not considered there.
Anyway you can test it and see if it improves performance by any useful amount. If not leave it enabled.
Steve
-
I'd expect the spectre mitigations to be more costly than meltdown, and arguably less relevant.
-
@vamike looking at the processes running on my router, unbound and dhcpd are the only two things not running as root. So given that it seems that avoiding meltdown/spectre on a native bare-metal install is fine. Anything that can take advantage of meltdown or spectre would likely simply take advantage of being root.
-
Kernel PTI disabled and net.isr.dispatch=deferred
A little bit better than I was getting before the meltdown patch with dispatch=direct
Not too shabby.
-
@w0w said in Gigabit PPPoE and Intel Drivers:
There are some updates in FreeBSD bug report — https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
Can someone test this possible solution suggested?
In terminal dosysctl net.isr.dispatch=deferred
Try some gigabit tests, like dslreports or whatever. Check for your speeds and report it here, please.
Thanks, that did it for me, allowing me to almost double my Rx on my realtek Nics on my Zotac box.. So glad, getting ~ 750/750 now.. which is good enough for now.
-
@doboy
If you read back a few posts you'll see some of my experiences. I actually had to disable the meltdown fixes as well to get back to close to what I was getting before. -
This post is deleted! -
50% CPU usage on that dual core CPU is probably 100% on one core if you;re checking on the dashboard.
Suricata can use the other core bringing it up to 100% total. You would have to check at the command line to see the CPU usage breakdown:top -aSH
.That is more that I would have thought but the single thread rating of the E4500 is significantly higher than, say, the J1900 that has been seen to be limited to ~500Mbps PPPoE. Though those Celerons seem particularly effected by this for some reason.
Steve
-
@stephenw10 said in Gigabit PPPoE and Intel Drivers:
That is more that I would have thought but the single thread rating of the E4500 is significantly higher than, say, the J1900 that has been seen to be limited to ~500Mbps PPPoE. Though those Celerons seem particularly effected by this for some reason.
Steve
Hi Steve, does this problem also/still affect the newer Celerons?
I have a 1000/100 FTTH link with PPPoE on it and I had almost settled on getting a Qotom Q515G6 with a Celeron 3865U and 6 x Intel I211-AT NICs as my first pfSense router, figuring it okay for my needs* but after finding this thread I'm wondering if the Celeron may choke on the PPPoE and I may need an i3?
*Typical home usage, 1 Gbps routing over PPPoE, light VPN server needs, firewall, NAT, pfBlockerNG with DNSBL and in and out IP lists filtering, light Suricata usage mostly for learning purposes.
P.S. congratulations for the great forum, I've been reading a lot of it in the last few days and it's been tremendously helpful.
-
@thegriffin said in Gigabit PPPoE and Intel Drivers:
Celeron 3865U
The single thread rating of that is higher than the E4500 so if it scales directly I would expect it to be fine. I have never tested one though. All CPUs are affected.
Steve
-
Thanks for the input Steve, then I'll stick to that one.
-
This post is deleted! -
Hi Tony, thanks for your post. Yes an 8th gen i5 is a lot of power, maybe you could use it for something else too with virtualization.
I'm probably going for the 3865U Celeron as it would be fine for my use, only this PPPoE issue was making me doubt but now I'm sure it'll be good.
I could get an i3-7100U regardless, though possibly a good chunk the 70 euros difference is for the marketing, but then for only 30 euros more I could get an i5-7200U and at that point I'll have upsold to myself once more
-
Hi guys, I've found another box (Partaker) that has Intel 82583V NICs (em driver) instead of the Intel I211-AT (igb driver), per this thread the em driver mitigates the PPPoE issue.
The box also has a few other advantages and I'm about to pull the trigger, my only doubt is those NICs are older (discontinued Q1 2020 vs. 1H 2029 planned for the I211-AT).
In your opinion what's the risk that they'll become unsupported in the not too distant future? I'm not that concerned about FreeBSD, more about ESXi in case I want to use virtualization in future (not planning to for now).
Thanks for sharing your thoughts.
EDIT: the processor would be either a Celeron 3865U or an i3-7100U and as per the above posts either should manage wire speed regardless of the NICs driver, still if the em driver means less CPU effort all the better and as I mentioned the Partaker box has other advantages over the Qotom and other boxes with the I211-AT NICs.
-
The PPPoE issue affects all drivers/NICs AFIAK.
The issue is that it can only use a single queue for pppoe traffic so only a single CPU core which limits throughput.
It doesn't effect em NICs because they are single queue anyway, equally limited performance for all protocols. igb is multi-queue for anything it can use RSS on which is IP traffic.
I'm not aware of any NIC that can hash pppoe traffic to use RSS.https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856#c11
Steve