On 19.01.2025 04:46, Timothy Pearson wrote:
Forcibly disabling RSS with the IPSec deferred patch seems to have
fixed the issue. Given the wide ranging deleterious effects with RSS
on vs. a bit of IPsec theoretical maximum bandwidth loss with it off,
we'll take the bandwidth hit at the moment. ;)
How did you disable RSS?
Usually when you have one of netisr threads overloaded, this means that
you got received a lot of packets that are handled by one CPU core. This
can be NIC that dispatches them via RSS or there is something that
forces to handle them on single core, i.e. firewall, dummynet.
Are there any significant concerns with running the patch for
deferred IPSec input? From my analysis of the code, I think the
absolute worst case might be a reordered packet or two, but that's
always possible with IPSec over UDP transport AFAIK.
The mentioned patch seems does direct processing in your case, not
deferred, since you had configured net.isr.dispatch=direct.
--
WBR, Andrey V. Elsukov
