[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220825143610.4f13f730@kernel.org>
Date: Thu, 25 Aug 2022 14:36:10 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Leon Romanovsky <leon@...nel.org>
Cc: Steffen Klassert <steffen.klassert@...unet.com>,
Leon Romanovsky <leonro@...dia.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
Raed Salem <raeds@...dia.com>,
Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [PATCH xfrm-next v3 0/6] Extend XFRM core to allow full offload
configuration
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.
Powered by blists - more mailing lists