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:   Mon, 5 Dec 2022 10:23:04 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Leon Romanovsky <leon@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        <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 11:52:13AM -0800, Jakub Kicinski wrote:
> On Fri, 2 Dec 2022 21:45:47 +0200 Leon Romanovsky wrote:
> > > More of a question of whether we can reasonably expect to merge all 
> > > the driver code in a single release cycle. If not then piecemeal
> > > merging is indeed inevitable. But if Steffen is happy with the core
> > > changes whether they are in tree for 6.2 or not should not matter.
> > > An upstream user can't access them anyway, it'd only matter to an
> > > out-of-tree consumer.
> > > 
> > > That's just my 2 cents, whatever Steffen prefers matters most.  
> > 
> > There are no out-of-tree users, just ton of mlx5 refactoring to natively
> > support packet offload.
> 
> 30 patches is just two series, that's mergeable in a week.
> You know, if it builds cleanly.. :S  Dunno.

The core changes are ready, so there is no real reason
to hold them off.

I had not yet a closer look to the driver changes, though.

I've just updated ipsec-next, whatever builds with ipsec-next
should build with net-next now. In case the driver changes
do not genarate any fallouts, I can take them into ipsec-next
as well.

The two driver series and the core series would be about 40
patches. If you are ok with taking such a last minute PR
into net-next, we can go that way.