From: Jihong Min <hurryman2212@gmail.com>
To: netdev@vger.kernel.org
Cc: Jay Vosburgh <jv@jvosburgh.net>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Steffen Klassert <steffen.klassert@secunet.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
linux-kernel@vger.kernel.org, Jihong Min <hurryman2212@gmail.com>
Subject: [PATCH RFC net-next 0/4] bonding: support LAG IPsec offload with replicated SAs
Date: Wed, 20 May 2026 17:10:00 +0900 [thread overview]
Message-ID: <20260520081004.2232091-1-hurryman2212@gmail.com> (raw)
This RFC adds a bonding model for IPsec/XFRM hardware offload on
802.3ad and balance-xor LAG devices when the transmit hash policy is
layer3+4. This is an intentional scope limit rather than a hard limit,
as this is the configuration I can test with my gear.
The main idea is to leave the existing upstream single-lower-device XFRM
offload path for active-backup intentionally untouched, while adding a
replicated state model for LAG.
For LAG bonds, the bonding driver installs the same XFRM state on every
eligible running slave and stores the per-slave hardware handles in
bonding-private state. Lower drivers that support this model can then
resolve the handle for the concrete lower netdev used by the datapath.
LAG IPsec features are user controlled. Newly eligible LAG bonds start
with the ESP/XFRM features disabled, but advertise supported mutable
features when all running eligible slaves can support them. Users can
then opt in with ethtool. Feature enable is propagated to the lower
devices and rolled back if a lower device cannot enable the requested
features.
The series also handles LAG membership and eligibility changes by adding
replicated SAs to newly usable slaves, removing the departing lower
instance on down/remove, and flushing bond-owned XFRM offload state when
the bond leaves the supported mode or hash-policy configuration.
This series does not convert any physical NIC driver. A lower driver
must explicitly opt in to the replicated-upper-device model before it can
use these bond-owned states in its datapath.
For example, a driver such as mlx5 would opt in by marking its
xfrmdev_ops and by resolving datapath handles through the helper:
static const struct xfrmdev_ops mlx5e_ipsec_xfrmdev_ops = {
...
.xdo_dev_state_lower_handle = NULL,
.flags = XFRMDEV_OPS_F_LOWER_HANDLE,
};
handle = xfrm_dev_state_lower_handle(x, netdev);
if (!handle)
goto drop;
sa_entry = (struct mlx5e_ipsec_sa_entry *)handle;
Jihong Min (4):
xfrm: add a lower-device offload handle resolver
bonding: replicate XFRM offload state across LAG slaves
bonding: expose user-controlled IPsec features for LAG
bonding: handle replicated IPsec SAs across LAG changes
drivers/net/bonding/bond_main.c | 855 ++++++++++++++++++++++++++++-
drivers/net/bonding/bond_options.c | 59 +-
include/linux/netdevice.h | 27 +
include/net/bonding.h | 29 +-
include/net/xfrm.h | 48 +-
net/xfrm/xfrm_state.c | 1 +
6 files changed, 1000 insertions(+), 19 deletions(-)
base-commit: 27fa82620cbaa89a7fc11ac3057701d598813e87
--
2.53.0
next reply other threads:[~2026-05-20 8:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 8:10 Jihong Min [this message]
2026-05-20 8:10 ` [PATCH RFC net-next 1/4] xfrm: add a lower-device offload handle resolver Jihong Min
2026-05-20 8:10 ` [PATCH RFC net-next 2/4] bonding: replicate XFRM offload state across LAG slaves Jihong Min
2026-05-20 8:10 ` [PATCH RFC net-next 3/4] bonding: expose user-controlled IPsec features for LAG Jihong Min
2026-05-20 8:10 ` [PATCH RFC net-next 4/4] bonding: handle replicated IPsec SAs across LAG changes Jihong Min
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=20260520081004.2232091-1-hurryman2212@gmail.com \
--to=hurryman2212@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=horms@kernel.org \
--cc=jv@jvosburgh.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=steffen.klassert@secunet.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