[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220822084105.GI2602992@gauss3.secunet.de>
Date: Mon, 22 Aug 2022 10:41:05 +0200
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: Jason Gunthorpe <jgg@...dia.com>,
Leon Romanovsky <leon@...nel.org>,
"David S . Miller" <davem@...emloft.net>,
Herbert Xu <herbert@...dor.apana.org.au>,
<netdev@...r.kernel.org>, Raed Salem <raeds@...dia.com>,
ipsec-devel <devel@...ux-ipsec.org>
Subject: Re: [PATCH xfrm-next v2 0/6] Extend XFRM core to allow full offload
configuration
On Fri, Aug 19, 2022 at 10:53:56AM -0700, Jakub Kicinski wrote:
> On Fri, 19 Aug 2022 13:01:22 -0300 Jason Gunthorpe wrote:
> > Regardless, RDMA doesn't really intersect with this netdev work for
> > XFRM beyond the usual ways that RDMA IP traffic can be captured by or
> > run parallel to netdev.
> >
> > A significant use case here is for switchdev modes where the switch
> > will subject traffic from a switch port to ESP, not unlike it already
> > does with vlan, vxlan, etc and other already fully offloaded switching
> > transforms.
>
> Yup, that's what I thought you'd say. Can't argue with that use case
> if Steffen is satisfied with the technical aspects.
Yes, everything that can help to overcome the performance problems
can help and I'm interested in this type of offload. But we need to
make sure the API is usable by the whole community, so I don't
want an API for some special case one of the NIC vendors is
interested in.
Powered by blists - more mailing lists