[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221122130002.GM704954@gauss3.secunet.de>
Date: Tue, 22 Nov 2022 14:00:02 +0100
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Leon Romanovsky <leon@...nel.org>
CC: Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, <netdev@...r.kernel.org>
Subject: Re: [PATCH xfrm-next v7 6/8] xfrm: speed-up lookup of HW policies
On Tue, Nov 22, 2022 at 08:27:48AM +0200, Leon Romanovsky wrote:
> On Tue, Nov 22, 2022 at 12:29:12PM +0800, Herbert Xu wrote:
> > On Mon, Nov 21, 2022 at 03:21:45PM +0200, Leon Romanovsky wrote:
> > >
> > > The thing is that this SW acquire flow is a fraction case, as it applies
> > > to locally generated traffic.
> >
> > A router can trigger an acquire on forwarded packets too. Without
> > larvals this could quickly overwhelm the router.
>
> This series doesn't support tunnel mode yet.
It does not matter if tunnel or transport mode, acquires must
work as expected. This is a fundamental concept of IPsec, there
is no way to tell userspace that we don't support this.
> Maybe I was not clear, but I wanted to say what in eswitch case and
> tunnel mode, the packets will be handled purely by HW without raising
> into SW core.
Can you please explain why we need host interaction for
transport, but not for tunnel mode?
Staying away with HW policies and states from SW databases is what
I wanted to have from the beginning. If that is possible for tunnel
mode, it should be possible for transport mode too.
And as said already, I want to see the full picture (transport
+ tunnel mode) before we merge it.
Powered by blists - more mailing lists