2025-06-05, 17:16:24 +0300, Leon Romanovsky wrote:

On Thu, Jun 05, 2025 at 03:09:19PM +0200, Sabrina Dubroca wrote:

quoted

Hello,

I think we need to revert this patch. It causes a severe performance
regression for SW IPsec (around 40-50%).

2025-02-19, 15:50:57 +0200, Leon Romanovsky wrote:

quoted

From: Leon Romanovsky <leonro@nvidia.com>

XFRM offload path is probed even if offload isn't needed at all. Let's
make sure that x->type_offload pointer stays NULL for such path to
reduce ambiguity.

x->type_offload is used for GRO with SW IPsec, not just for HW offload.

Thanks for the report, can you please try the following fix?

Seems to work in my setup. That's basically a revert of every
functional change in 585b64f5a620 ("xfrm: delay initialization of
offload path till its actually requested"), except that now we set
->type_offload during xfrm_state_construct instead of
__xfrm_init_state, so other callers of __xfrm_init_state
(xfrm_state_migrate and pfkey - we can ignore ipcomp since it doesn't
have ->type_offload) won't get ->type_offload set correctly. I'm not
sure we want that.

Do you need to also revert 49431af6c4ef ("xfrm: rely on XFRM offload")
from this series? The assumption that x->type_offload is set only for
HW offload isn't correct.

-- 
Sabrina