From: Jakub Kicinski <kuba@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
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 11:56:27 -0700 [thread overview]
Message-ID: <20220830115627.27099213@kernel.org> (raw)
In-Reply-To: <Yw5KtJ+vOoi+qSM6@nvidia.com>
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.
Sorry, perhaps I assumed we were on the same page too hastily.
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.
That necessitates full offload, and therefore can be used as a strong
argument for having a full offload in netdev.
> We other use-models, like the offloaded OVS switching model you are
> alluding to, that is Leon has as a followup.
next prev parent reply other threads:[~2022-08-30 18:56 UTC|newest]
Thread overview: 19+ 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 ` [Intel-wired-lan] [PATCH xfrm-next v3 2/6] xfrm: allow state full offload mode Leon Romanovsky
2022-08-23 13:31 ` 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 [this message]
2022-08-30 22:34 ` Jason Gunthorpe
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=20220830115627.27099213@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=jgg@nvidia.com \
--cc=leon@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=raeds@nvidia.com \
--cc=saeedm@nvidia.com \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.