From: Jakub Kicinski <kuba@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: Steffen Klassert <steffen.klassert@secunet.com>,
Leon Romanovsky <leonro@nvidia.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: Thu, 25 Aug 2022 14:36:10 -0700 [thread overview]
Message-ID: <20220825143610.4f13f730@kernel.org> (raw)
In-Reply-To: <cover.1661260787.git.leonro@nvidia.com>
On Tue, 23 Aug 2022 16:31:57 +0300 Leon Romanovsky wrote:
> * I didn't hear any suggestion what term to use instead of
> "full offload", so left it as is. It is used in commit messages
> and documentation only and easy to rename.
> * Added performance data and background info to cover letter
> * Reused xfrm_output_resume() function to support multiple XFRM transformations
> * Add PMTU check in addition to driver .xdo_dev_offload_ok validation
> * Documentation is in progress, but not part of this series yet.
Since the use case is somewhat in question, perhaps switch to RFC
postings until the drivers side incl. tc forwarding is implemented?
Also the perf traces, I don't see them here.
next prev parent reply other threads:[~2022-08-25 21:36 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 ` Jakub Kicinski [this message]
2022-08-26 6:26 ` [PATCH xfrm-next v3 0/6] Extend XFRM core to allow full offload configuration 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
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=20220825143610.4f13f730@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=leon@kernel.org \
--cc=leonro@nvidia.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).