netdev - Re: [PATCH xfrm-next v9 0/8] Extend XFRM core to allow packet offload configuration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 2 Dec 2022 20:05:19 +0200
From:   Leon Romanovsky <leon@...nel.org>
To:     Steffen Klassert <steffen.klassert@...unet.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Bharat Bhushan <bbhushan2@...vell.com>
Subject: Re: [PATCH xfrm-next v9 0/8] Extend XFRM core to allow packet
 offload configuration

On Fri, Dec 02, 2022 at 10:42:43AM +0100, Steffen Klassert wrote:
> On Sun, Nov 27, 2022 at 01:18:10PM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@...dia.com>
> > 
> > Changelog:
> > v9:
> >  * Added acquire support
> > v8: https://lore.kernel.org/all/cover.1668753030.git.leonro@nvidia.com
> >  * Removed not-related blank line
> >  * Fixed typos in documentation
> > v7: https://lore.kernel.org/all/cover.1667997522.git.leonro@nvidia.com
> > As was discussed in IPsec workshop:
> >  * Renamed "full offload" to be "packet offload".
> >  * Added check that offloaded SA and policy have same device while sending packet
> >  * Added to SAD same optimization as was done for SPD to speed-up lookups.
> > v6: https://lore.kernel.org/all/cover.1666692948.git.leonro@nvidia.com
> >  * Fixed misplaced "!" in sixth patch.
> > v5: https://lore.kernel.org/all/cover.1666525321.git.leonro@nvidia.com
> >  * Rebased to latest ipsec-next.
> >  * Replaced HW priority patch with solution which mimics separated SPDs
> >    for SW and HW. See more description in this cover letter.
> >  * Dropped RFC tag, usecase, API and implementation are clear.
> > v4: https://lore.kernel.org/all/cover.1662295929.git.leonro@nvidia.com
> >  * Changed title from "PATCH" to "PATCH RFC" per-request.
> >  * Added two new patches: one to update hard/soft limits and another
> >    initial take on documentation.
> >  * Added more info about lifetime/rekeying flow to cover letter, see
> >    relevant section.
> >  * perf traces for crypto mode will come later.
> > v3: https://lore.kernel.org/all/cover.1661260787.git.leonro@nvidia.com
> >  * I didn't hear any suggestion what term to use instead of
> >    "packet 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.
> > v2: https://lore.kernel.org/all/cover.1660639789.git.leonro@nvidia.com
> >  * Rebased to latest 6.0-rc1
> >  * Add an extra check in TX datapath patch to validate packets before
> >    forwarding to HW.
> >  * Added policy cleanup logic in case of netdev down event
> > v1: https://lore.kernel.org/all/cover.1652851393.git.leonro@nvidia.com
> >  * Moved comment to be before if (...) in third patch.
> > v0: https://lore.kernel.org/all/cover.1652176932.git.leonro@nvidia.com
> > -----------------------------------------------------------------------
> 
> Please move the Changelog to the end of the commit message.
> 
> Except of the minor nit I had in patch 4/8, the patchset looks
> ready for merging. I'd prefer to merge it after the upcomming
> merge window. But Linus might do a rc8, so I leave it up to you
> in that case.

I'm sending new version now and my preference is to merge it in this
cycle. It will allow us to easily merge mlx5 part in next cycle without
any ipsec tree involvement. You won't need to apply and deal with any
merge conflicts which can bring our code :).

Of course, we will CC you and ipsec ML.

Thanks