Subject: Re: [PATCH xfrm-next v3 0/6] Extend XFRM core to allow full offload configuration

From: Jason Gunthorpe <[email-masked]>
Date: Tue, 30 Aug 2022 19:34:14 -0300

On Tue, Aug 30, 2022 at 11:56:27AM -0700, Jakub Kicinski wrote:
> On Tue, 30 Aug 2022 14:36:52 -0300 Jason Gunthorpe wrote:
> > I was meaning rather generically handling the packets in the
> > hypervisor side without involving the CPU. 
> > 
> > We have customers deploying many different models for this in their
> > hypervisor, including a significant deployment using a model like the
> > above. 
> > 
> > It achieves a kind of connectivity to a VM with 0 hypervisor CPU
> > involvement with the vlan push/pop done in HW.
> 
> I don't see how that necessitates the full IPsec offload.

I think it would help if Leon showed the xfrm commands in his
configuration snippet and explained the traffic flow that is achieved
by it.

He has a configuration that is as I described, 0 hypervisor CPU
involvement, IPSEC, and VMs.

> Sorry, perhaps I assumed we were on the same page too hastily.

Well, I think we all agree that if a hypervisor environment is
controlling the IPSEC then we'd like a path similar to others where
the hypervisor doesn't process the packets in the CPU - it just flows
in the HW right out of the VM.

It seems obvious, but this means that the hypervisor controls HW that
does the crypto, the anti-replay, the counting and limiting
"autonomously" from the hypervisor CPU. (the so-called "full offload")

> I was referring to a model where the TC rules redirect to a IPsec
> tunnel which is then routed to the uplink. All offloaded. Like
> we do today for VxLAN encap/decap.

I think there are several models with TC that can do this. It is
probably worth talking about exactly which models should and need to
have it.

eg what exactly do you mean when you say "TC rules redirect to a IPsec
tunnel" ? How does a TC rule redirect to an xfrm?

Jason