[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230814082128.632d2b03@kernel.org>
Date: Mon, 14 Aug 2023 08:21:28 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: netdev@...r.kernel.org, Vadim Fedorenko <vfedorenko@...ek.ru>, Frantisek
Krenzelok <fkrenzel@...hat.com>, Kuniyuki Iwashima <kuniyu@...zon.com>,
Apoorv Kothari <apoorvko@...zon.com>, Boris Pismenny <borisp@...dia.com>,
John Fastabend <john.fastabend@...il.com>, Shuah Khan <shuah@...nel.org>,
linux-kselftest@...r.kernel.org, Gal Pressman <gal@...dia.com>, Marcel
Holtmann <marcel@...tmann.org>
Subject: Re: [PATCH net-next v3 3/6] tls: implement rekey for TLS1.3
On Mon, 14 Aug 2023 17:06:10 +0200 Sabrina Dubroca wrote:
> 2023-08-11, 18:43:47 -0700, Jakub Kicinski wrote:
> > On Wed, 9 Aug 2023 14:58:52 +0200 Sabrina Dubroca wrote:
> > > TLS_INC_STATS(sock_net(sk), LINUX_MIB_TLSRXSW);
> > > TLS_INC_STATS(sock_net(sk), LINUX_MIB_TLSCURRRXSW);
> > > conf = TLS_SW;
> >
> > Should we add a statistic for rekeying?
>
> Hmpf, at least I shouldn't be incrementing the existing stats on every
> update, especially not TLSCURR* :/
>
> I don't see much benefit in tracking succesful rekeys. Failed rekeys
> seem more interesting to me. What would we get from counting succesful
> rekeys?
No huge benefit from counting rekeys, the main (only?) one I see is
that when user reports issues we can see whether rekeys were involved
(given that they are fairly rare). It could help narrow down triage.
Powered by blists - more mailing lists