In 2001 cycle, there was a change [0] in the ipsec code. It moved the logic away from dedicated ipsec interfaces to more general ipip interfaces. Ideally, this should not affect the ipsec processing throughput. Alternatively, performance impact should be minimal.

But in 2001 CSIT report, there were regressions in ipsec tests, some larger than 5%.
See line with imix-1t1c-ethip4ipsec10000tnlsw-ip4base-int-aes256gcm here [1]
and line with 64b-2t1c-ethip4ipsec10000tnlsw-ip4base-int-aes256gcm here [2].

Using bisection for 3n-hsw test case 64B-1c-ethip4ipsec10000tnlsw-ip4base-int-aes256gcm,
it was confirmed that 22878 causes the PDR lower bound to decrease from ~2.6 Mpps to ~2.4 Mpps.
See comments in CSIT-1712 for details; the situation is complicated by the fact 22878 introduces an API (well, CLI) change CSIT needed to adapt to, and there is an overlapping dpdk-related breakage on VPP side.

A VPP developer is needed to verify whether the regression is unavoidable; and to fix VPP if not.

[0] https://gerrit.fd.io/r/c/vpp/+/22878
[1] https://docs.fd.io/csit/rls2001/report/_static/vpp/performance-changes-3n-hsw-1t1c-pdr.txt
[2] https://docs.fd.io/csit/rls2001/report/_static/vpp/performance-rca-3n-skx-2t1c-pdr.txt