All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Daniel Zahka <daniel.zahka@gmail.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	Donald Hunter <donald.hunter@gmail.com>,
	Boris Pismenny <borisp@nvidia.com>,
	Saeed Mahameed <saeedm@nvidia.com>,
	Leon Romanovsky <leon@kernel.org>,
	Tariq Toukan <tariqt@nvidia.com>, Mark Bloch <mbloch@nvidia.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	Shuah Khan <shuah@kernel.org>,
	netdev@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net-next 0/9] psp: support rekeying psp protected tcp connections
Date: Fri, 6 Feb 2026 20:18:29 -0800	[thread overview]
Message-ID: <20260206201829.45fd9675@kernel.org> (raw)
In-Reply-To: <f3560398-d6fa-4f05-9496-f0e59a5c0fd2@gmail.com>

On Wed, 4 Feb 2026 16:43:46 -0500 Daniel Zahka wrote:
> On 2/4/26 3:45 PM, Willem de Bruijn wrote:
> > Daniel Zahka wrote:  
> >> In the case of tx rekeying, as soon as we install the new tx key, we
> >> have no use for the previous one, and it can be disposed of
> >> immediately.  
> > So this defines a rekey event as an instant in time. An alternative
> > choice is to rekey at a specific seqno.
> >
> > The difference matters only for retransmits.
> >
> > Not sure there is a strong reason for either. But probably good to
> > state the choice explicitly.  
> 
> I suppose if we think about a rekey as occurring at a seqno we could do 
> away with the deferred key deletion, and instead just wait for data sent 
> before that seqno to be ack'd before deleting the key. I would say if 
> nothing else that would be a significant improvement over what I have 
> right now.

If you mean the driver xmit problem - not sure this changed much,
a (spurious) retransmission may theoretically still be queued on 
the driver ring when data is acked.

  reply	other threads:[~2026-02-07  4:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-04 15:20 [PATCH net-next 0/9] psp: support rekeying psp protected tcp connections Daniel Zahka
2026-02-04 15:20 ` [PATCH net-next 1/9] psp: support rx rekey operation Daniel Zahka
2026-02-07  4:24   ` Jakub Kicinski
2026-02-07  4:32   ` [net-next,1/9] " Jakub Kicinski
2026-02-04 15:20 ` [PATCH net-next 2/9] psp: move code from psp_sock_assoc_set_tx() into helper functions Daniel Zahka
2026-02-04 20:46   ` Willem de Bruijn
2026-02-04 15:20 ` [PATCH net-next 3/9] psp: support tx rekey operation Daniel Zahka
2026-02-04 15:20 ` [PATCH net-next 4/9] psp: refactor psp_dev_tx_key_del() Daniel Zahka
2026-02-04 20:46   ` Willem de Bruijn
2026-02-04 15:20 ` [PATCH net-next 5/9] psp: add driver api for deferred tx key deletion Daniel Zahka
2026-02-04 15:20 ` [PATCH net-next 6/9] psp: add core tracked stats for deferred " Daniel Zahka
2026-02-04 15:20 ` [PATCH net-next 7/9] mlx5: psp: implement deferred tx " Daniel Zahka
2026-02-07  4:30   ` Jakub Kicinski
2026-02-07  4:32   ` [net-next,7/9] " Jakub Kicinski
2026-02-04 15:20 ` [PATCH net-next 8/9] selftests: drv-net: psp: lift psp connection setup out of _data_basic_send() testcase Daniel Zahka
2026-02-04 20:49   ` Willem de Bruijn
2026-02-04 15:20 ` [PATCH net-next 9/9] selftests: drv-net: psp: add tests for rekeying connections Daniel Zahka
2026-02-04 20:45 ` [PATCH net-next 0/9] psp: support rekeying psp protected tcp connections Willem de Bruijn
2026-02-04 21:43   ` Daniel Zahka
2026-02-07  4:18     ` Jakub Kicinski [this message]
2026-02-07  4:21 ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260206201829.45fd9675@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=borisp@nvidia.com \
    --cc=daniel.zahka@gmail.com \
    --cc=davem@davemloft.net \
    --cc=donald.hunter@gmail.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mbloch@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=saeedm@nvidia.com \
    --cc=shuah@kernel.org \
    --cc=tariqt@nvidia.com \
    --cc=willemdebruijn.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.