RSS on CL PPPoE

[cirkutbraker]

So I somehow skipped the part about the new RSS feature not working with PPPoE and enabled it.

I'm seeing HUGE performance improvement.

Before:

Code: [Select]

Speedtest by Ookla

Server: Green House Data, Inc - Seattle, WA (id = 11329)
ISP: CenturyLink
Latency:     2.01 ms   (0.40 ms jitter)
Download:   550.53 Mbps (data used: 468.2 MB)                               
Upload:   809.91 Mbps (data used: 387.5 MB)                               
Packet Loss:     0.0%

After:

Code: [Select]

Speedtest by Ookla

Server: Whitesky Communications LLC - Seattle, WA (id = 22168)
ISP: CenturyLink
Latency:     2.88 ms   (0.12 ms jitter)
Download:   917.81 Mbps (data used: 471.2 MB)                               
Upload:   906.24 Mbps (data used: 631.9 MB)                               
Packet Loss:     0.0%

This is the same current release 21.7.4 kernel tested before without the tunable and after the tunable "net.inet.rss.enabled" set to value "1".

I'd like to know more about how it's not compatible with PPPoE because I'm inclined to leave it enabled with this improvement (edit: I did review this thread: https://redmine.pfsense.org/issues/4821 but it's all over the place in terms of "it works" vs "it doesn't/can't")

(note that the first test results are very consistent over the course of my use of opnsense on this centurylink fiber connection)

Running on a Protectli Vault 4 Port, 8gb ram, Intel(R) Celeron(R) CPU J3160 @ 1.60GHz (4 cores)

[franco]

Hi cirkutbraker,

Thanks for checking out RSS! 

While PPPoE does have nothing to gain from RSS the side effect form RSS is that PPPoE connections get pinned to CPU 0 for incoming and outgoing connections alike.

That means for certain hardware combinations CPU count / hyperthreading / network chipsets could benefit from the CPU-bound limitation under light load (not much else but speed test running).

Did you use any previous tweaks like net.isr.dispatch=deferred tunable?  Because I think RSS undoes that...


Cheers,
Franco

[cirkutbraker]

Did you use any previous tweaks like net.isr.dispatch=deferred tunable?  Because I think RSS undoes that...

Franco, I did have that tunable set ( net.isr.dispatch=deferred ). Still set, so I'm assuming this means RSS takes precedence and reverts the net.isr.dispatch deferred value.

Given that light load performance looks better, the question is whether heavy load suffers enough to unset RSS on this box. Thoughts? I'll test of course, but welcoming feedback on this. Hard to give up those new peak numbers