From: Jason Gunthorpe <jgg@nvidia•com>
To: Jakub Kicinski <kuba@kernel•org>
Cc: Leon Romanovsky <leon@kernel•org>,
Steffen Klassert <steffen.klassert@secunet•com>,
"David S. Miller" <davem@davemloft•net>,
Eric Dumazet <edumazet@google•com>,
Herbert Xu <herbert@gondor•apana.org.au>,
netdev@vger•kernel.org, Paolo Abeni <pabeni@redhat•com>,
Raed Salem <raeds@nvidia•com>, Saeed Mahameed <saeedm@nvidia•com>
Subject: Re: [PATCH xfrm-next v3 0/6] Extend XFRM core to allow full offload configuration
Date: Tue, 30 Aug 2022 19:34:14 -0300 [thread overview]
Message-ID: <Yw6QZr9QUwPX+aFY@nvidia.com> (raw)
In-Reply-To: <20220830115627.27099213@kernel.org>
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
next prev parent reply other threads:[~2022-08-30 22:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 13:31 [PATCH xfrm-next v3 0/6] Extend XFRM core to allow full offload configuration Leon Romanovsky
2022-08-23 13:31 ` [PATCH xfrm-next v3 1/6] xfrm: add new full offload flag Leon Romanovsky
2022-08-23 13:31 ` [PATCH xfrm-next v3 2/6] xfrm: allow state full offload mode Leon Romanovsky
2022-08-23 13:32 ` [PATCH xfrm-next v3 3/6] xfrm: add an interface to offload policy Leon Romanovsky
2022-08-23 13:32 ` [PATCH xfrm-next v3 4/6] xfrm: add TX datapath support for IPsec full offload mode Leon Romanovsky
2022-08-23 13:32 ` [PATCH xfrm-next v3 5/6] xfrm: add RX datapath protection " Leon Romanovsky
2022-08-23 13:32 ` [PATCH xfrm-next v3 6/6] xfrm: enforce separation between priorities of HW/SW policies Leon Romanovsky
2022-08-25 21:36 ` [PATCH xfrm-next v3 0/6] Extend XFRM core to allow full offload configuration Jakub Kicinski
2022-08-26 6:26 ` Leon Romanovsky
2022-08-26 23:45 ` Jakub Kicinski
2022-08-28 9:28 ` Leon Romanovsky
2022-08-30 17:36 ` Jason Gunthorpe
2022-08-30 18:56 ` Jakub Kicinski
2022-08-30 22:34 ` Jason Gunthorpe [this message]
2022-08-29 8:07 ` Steffen Klassert
2022-08-29 7:54 ` Steffen Klassert
2022-08-30 6:48 ` Leon Romanovsky
2022-09-04 16:45 ` Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yw6QZr9QUwPX+aFY@nvidia.com \
--to=jgg@nvidia$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=kuba@kernel$(echo .)org \
--cc=leon@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=raeds@nvidia$(echo .)com \
--cc=saeedm@nvidia$(echo .)com \
--cc=steffen.klassert@secunet$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox