netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steffen Klassert <steffen.klassert@secunet.com>
To: Sabrina Dubroca <sd@queasysnail.net>
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 14:30:41 +0200	[thread overview]
Message-ID: <ZsXd8adxUtip773L@gauss3.secunet.de> (raw)
In-Reply-To: <ZsS3Zh8bT-qc46s7@hog>

On Tue, Aug 20, 2024 at 05:33:58PM +0200, Sabrina Dubroca wrote:
> Hi Hangbin,
> 
> (adding Steffen since we're getting a bit into details of IPsec)
> 
> 2024-08-20, 08:48:39 +0800, Hangbin Liu wrote:
> > Currently, users can see that bonding supports IPSec HW offload via ethtool.
> > However, this functionality does not work with NICs like Mellanox cards when
> > ESN (Extended Sequence Numbers) is enabled, as ESN functions are not yet
> > supported. This patch adds ESN support to the bonding IPSec device offload,
> > ensuring proper functionality with NICs that support ESN.
> > 
> > Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
> > Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> > ---
> >  drivers/net/bonding/bond_main.c | 25 +++++++++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> > 
> > diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> > index 560e3416f6f5..24747fceef66 100644
> > --- a/drivers/net/bonding/bond_main.c
> > +++ b/drivers/net/bonding/bond_main.c
> > @@ -651,10 +651,35 @@ static bool bond_ipsec_offload_ok(struct sk_buff *skb, struct xfrm_state *xs)
> >  	return err;
> >  }
> >  
> > +/**
> > + * 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?

  parent reply	other threads:[~2024-08-21 12:30 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 [this message]
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
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=ZsXd8adxUtip773L@gauss3.secunet.de \
    --to=steffen.klassert@secunet.com \
    --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=sd@queasysnail.net \
    --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).