Netdev List
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Jihong Min <hurryman2212@gmail.com>
Cc: netdev@vger.kernel.org, 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
Subject: Re: [PATCH RFC net-next 0/4] bonding: support LAG IPsec offload with replicated SAs
Date: Wed, 10 Jun 2026 17:18:43 +0300	[thread overview]
Message-ID: <20260610141843.GI327369@unreal> (raw)
In-Reply-To: <20260520081004.2232091-1-hurryman2212@gmail.com>

On Wed, May 20, 2026 at 05:10:00PM +0900, Jihong Min wrote:
> 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;

I’m curious how you replicate and maintain the hardware state across these
devices. How are you handling the anti-replay window?

Thanks

> 
> 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
> 

      parent reply	other threads:[~2026-06-10 14:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-20  8:10 [PATCH RFC net-next 0/4] bonding: support LAG IPsec offload with replicated SAs Jihong Min
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
2026-06-10 14:18 ` Leon Romanovsky [this message]

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=20260610141843.GI327369@unreal \
    --to=leon@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=horms@kernel.org \
    --cc=hurryman2212@gmail.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=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