[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y4pV6+LxhyDO2Ufz@unreal>
Date: Fri, 2 Dec 2022 21:45:47 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Steffen Klassert <steffen.klassert@...unet.com>,
"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:26:07AM -0800, Jakub Kicinski wrote:
> On Fri, 2 Dec 2022 20:31:46 +0200 Leon Romanovsky wrote:
> > Not really, it is a matter of trust.
>
> 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.
>
> > The driver exists https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=xfrm-next
> > and it is a lot of code (28 patches for now) which is more natural for us to route through
> > traditional path.
> >
> > If you are not convinced, I can post all these patches to the ML right now
> > and Steffen will send them to you.
Powered by blists - more mailing lists