netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Hangbin Liu <liuhangbin@gmail.com>,
	netdev@vger.kernel.org, Jay Vosburgh <j.vosburgh@gmail.com>,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	Nikolay Aleksandrov <razor@blackwall.org>,
	Tariq Toukan <tariqt@nvidia.com>, Jianbo Liu <jianbol@nvidia.com>,
	Simon Horman <horms@kernel.org>
Subject: Re: [PATCHv3 net-next 2/3] bonding: Add ESN support to IPSec HW offload
Date: Wed, 21 Aug 2024 19:20:46 +0200	[thread overview]
Message-ID: <ZsYh7mXwIRDFnI2m@hog> (raw)
In-Reply-To: <ZsXzlQQjMNymDkhJ@gauss3.secunet.de>

2024-08-21, 16:03:01 +0200, Steffen Klassert wrote:
> On Wed, Aug 21, 2024 at 03:39:48PM +0200, Sabrina Dubroca wrote:
> > 2024-08-21, 21:26:00 +0800, Hangbin Liu wrote:
> > > On Wed, Aug 21, 2024 at 02:30:41PM +0200, Steffen Klassert wrote:
> > > > > > +/**
> > > > > > + * bond_advance_esn_state - ESN support for IPSec HW offload
> > > > > > + * @xs: pointer to transformer state struct
> > > > > > + **/
> > > > > > +static void bond_advance_esn_state(struct xfrm_state *xs)
> > > > > > +{
> > > > > > +	struct net_device *real_dev;
> > > > > > +
> > > > > > +	rcu_read_lock();
> > > > > > +	real_dev = bond_ipsec_dev(xs);
> > > > > > +	if (!real_dev)
> > > > > > +		goto out;
> > > > > > +
> > > > > > +	if (!real_dev->xfrmdev_ops ||
> > > > > > +	    !real_dev->xfrmdev_ops->xdo_dev_state_advance_esn) {
> > > > > > +		pr_warn("%s: %s doesn't support xdo_dev_state_advance_esn\n", __func__, real_dev->name);
> > > > > 
> > > > > xdo_dev_state_advance_esn is called on the receive path for every
> > > > > packet when ESN is enabled (xfrm_input -> xfrm_replay_advance ->
> > > > > xfrm_replay_advance_esn -> xfrm_dev_state_advance_esn), this needs to
> > > > > be ratelimited.
> > > > 
> > > > How does xfrm_state offload work on bonding?
> > > > Does every slave have its own negotiated SA?
> > > 
> > > Yes and no. Bonding only supports xfrm offload with active-backup mode. So only
> > > current active slave keep the SA. When active slave changes, the sa on
> > > previous slave is deleted and re-added on new active slave.
> > 
> > It's the same SA, there's no DELSA+NEWSA when we change the active
> > slave (but we call xdo_dev_state_delete/xdo_dev_state_add to inform
> > the driver/HW), and only a single NEWSA to install the offloaded SA on
> > the bond device (which calls the active slave's xdo_dev_state_add).
> 
> Maybe I miss something, but how is the sequence number, replay window
> etc. transfered from the old to the new active slave?

With crypto offload, the stack sees the headers so it manages to keep
track and update its data, so it should have no problem feeding it
back to the next driver?

Note that if something in that area is broken, it would be broken
regardless of ESN.

-- 
Sabrina


  reply	other threads:[~2024-08-21 17:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-20  0:48 [PATCHv3 net-next 0/3] Bonding: support new xfrm state offload functions Hangbin Liu
2024-08-20  0:48 ` [PATCHv3 net-next 1/3] bonding: add common function to check ipsec device Hangbin Liu
2024-08-20 12:51   ` Nikolay Aleksandrov
2024-08-20  0:48 ` [PATCHv3 net-next 2/3] bonding: Add ESN support to IPSec HW offload Hangbin Liu
2024-08-20 15:33   ` Sabrina Dubroca
2024-08-21  2:32     ` Hangbin Liu
2024-08-21 12:30     ` Steffen Klassert
2024-08-21 13:26       ` Hangbin Liu
2024-08-21 13:39         ` Sabrina Dubroca
2024-08-21 14:03           ` Steffen Klassert
2024-08-21 17:20             ` Sabrina Dubroca [this message]
2024-08-22  7:12               ` Steffen Klassert
2024-08-22  0:33           ` Hangbin Liu
2024-08-22  7:10             ` Steffen Klassert
2024-08-22  8:33               ` Hangbin Liu
2024-08-23  8:24                 ` Steffen Klassert
2024-08-23 12:48                   ` Hangbin Liu
2024-08-22  8:39               ` Sabrina Dubroca
2024-08-22  9:55                 ` Steffen Klassert
2024-08-20  0:48 ` [PATCHv3 net-next 3/3] bonding: support xfrm state update Hangbin Liu
2024-08-20 14:38   ` Sabrina Dubroca

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=ZsYh7mXwIRDFnI2m@hog \
    --to=sd@queasysnail.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=j.vosburgh@gmail.com \
    --cc=jianbol@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=liuhangbin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=razor@blackwall.org \
    --cc=steffen.klassert@secunet.com \
    --cc=tariqt@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).