From: Hangbin Liu <hangbin.liu@linux.dev>
To: David Dai <zdai@linux.ibm.com>
Cc: jv@jvosburgh.net, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
pradeeps@linux.ibm.com
Subject: Re: [PATCH 1/1] bonding: crypto offload enabled, non-offload slave failover, rekey failed
Date: Thu, 10 Sep 2026 16:03:07 +0800 [thread overview]
Message-ID: <aqJkO4-49YtW4NxF@fedora> (raw)
In-Reply-To: <apphLbjfmRYknVNh@fedora>
On Fri, Sep 04, 2026 at 02:11:57PM +0800, Hangbin Liu wrote:
> On Thu, Sep 03, 2026 at 05:01:23PM -0500, David Dai wrote:
> > Create a bonding device (i.e. bond0) in active-backup mode, 2 slaves.
> > Active slave: offload capable interface (i.e. eth1), primary interface.
> > Backup slave: non-offload capable interface(i.e. eth2).
> > Configure strongswan service swantl.conf child SA "hw_offload = crypto"
> > Start strongswan service
> > IPSec Crytpo Offload is enabled on top of bond0. i.e.
> > ip xfrm state |grep offload
> > crypto offload parameters: dev bond0 dir out mode crypto
> > crypto offload parameters: dev bond0 dir in mode crypto
> >
> > Active slave eth1 takes adavantage of IPSec Crypto Offload capability.
> >
> > If active slave eth1 is down for any reason (i.e. eth1 link down):
> > ip link set down dev eth1
> > non-offload capable interface eth2 failover to becomes active slave.
> > The existing SAs can continue use software IPsec after failover.
> > Traffic still keeps going properly.
> >
> > However if eth1 link had not recovered yet, strongswan service does
> > new child SA rekey, or uses swanctl command to do new child SA rekey,
> > it will fail because active slave eth2 doesn't support crypto offload.
> > In bond_ipsec_add_sa routine, it returns -EINVAL now, which is
> > treated as fatal error by xfrm_dev_state_add routine in kernel xfrm.
> >
> > To make the non-offload active slave survive the child SA rekey, need
> > to make bond_ipsec_add_sa routine returns -EOPNOTSUPP instead when
> > active slave doesn't support IPsec Crypto offload, the xfrm will
> > gracefully fallback to create new SA using Software IPsec.
> > Network traffic can keep going.
> >
> > After offload capable interface eth1 link is up, becomes active slave,
> > next time strongswan child SA rekey will create a new SA which enables
> > crypto offload again.
> >
> > This way, network traffic is never interrupted, always keeps going.
> >
> > Signed-off-by: David Dai <zdai@linux.ibm.com>
> > Tested-by: David Dai <zdai@linux.ibm.com>
> > ---
> > drivers/net/bonding/bond_main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> > index ef9eb0c53c66..79fc892dab07 100644
> > --- a/drivers/net/bonding/bond_main.c
> > +++ b/drivers/net/bonding/bond_main.c
> > @@ -490,7 +490,7 @@ static int bond_ipsec_add_sa(struct net_device *bond_dev,
> > !real_dev->xfrmdev_ops->xdo_dev_state_add ||
> > netif_is_bond_master(real_dev)) {
> > NL_SET_ERR_MSG_MOD(extack, "Slave does not support ipsec offload");
> > - err = -EINVAL;
> > + err = -EOPNOTSUPP;
> > goto out;
> > }
> >
> > --
> > 2.55.0
> >
>
> The patch looks good to me. I am just not sure whether we should shorten
> the description. Let's wait for others' opinions.
>
BTW, please add
Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves")
if there is a next version.
next prev parent reply other threads:[~2026-09-10 8:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 22:01 [PATCH 1/1] bonding: crypto offload enabled, non-offload slave failover, rekey failed David Dai
2026-09-04 6:11 ` Hangbin Liu
2026-09-10 8:03 ` Hangbin Liu [this message]
2026-09-10 14:23 ` David Dai
2026-09-10 1:02 ` netdev-bot+sashiko
2026-09-10 22:30 ` David Dai
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=aqJkO4-49YtW4NxF@fedora \
--to=hangbin.liu@linux.dev \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jv@jvosburgh.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pradeeps@linux.ibm.com \
--cc=zdai@linux.ibm.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.